975 replies to this topic

[rickh]

 

I've bought this optical sensor:

 

https://www.pololu.com/product/2450

 

(Sharp GP2Y0A51SK0F)

 

Because I saw Tested was using this on their build:

 

http://www.tested.co...inball-machine/

 

They are using this with a Teensy board. Will i be able to use this sensor on the Pinscape Controller?

 

No, that's not one of the sensors the software currently supports.  It's open-source, and the plunger sensor framework has a nice modular design that lets you plug in new sensors, so you could add it if you're up for the project.  But I don't think it would be worth the trouble - those sensors are really pretty terrible.

 

You might also be able to make it work, kind of, by telling the software that it's a potentionmeter.  Those Sharp sensors produce analog voltages that can be read by an ADC, which is the same way the pot sensor works.  But there are two big problems.  The first is that the distance/voltage curve of the Sharp sensors is non-linear, so the motion won't look very natural without a compensating adjustment in the software.  The second, bigger obstacle is that the Sharp sensors are 5V devices, whereas the KL25Z is a 3.3V device, and it's not at all tolerant of 5V inputs.  To safely use it with the KL25Z, you'd have to set up something to shift the voltage to the safe 3.3V range.  A voltage divider might work, but I'm not sure how well - putting any kind of resistive load on the Sharp sensor might interact poorly with its electronics and make its response curve even stranger.

 

The really big problem with the Sharp sensors is that they have terrible precision and terrible hysteresis.  That's why I haven't bothered trying to address the problems above.

 

 

It looks like the board supports this type of board:

 

https://www.pololu.com/product/2489

 

(VL6180X time-of-flight sensor)

 

Right.  I assume you've read through this:

 

http://mjrnet.org/pi...php?sid=vl6180x

 

I don't think personally think these sensors are very good at plunger sensing either, frankly, but they're way better than the Sharp analog sensors, they're 3.3V compatible when you get one of those Pololu breakout boards, and the Pinscape software does have support specifically for them.

 

My recommendation if you want something cheap and simple is a pot sensor.  Those actually have considerably better precision than the VL6180X and they're probably even easier to set up physically.

 

http://mjrnet.org/pi...ide.php?sid=pot

 

MJR,

 

According to the spec the output does not exceed 2.5V.  I am bread-boarding an anti-log amp, perhaps with a gain of 1.32 to give it a full 3.3V FS.   I can't recall if your software does an inversion of the input, if not I''ll make the output inverting.  Anyway, I bought two of those sensors and if I get it to work, I'll post the results along with a schematic.  Question- this device samples at 60Hz.  I don't know what the ADC sample rate on the Freescale is.  Do you think there will be issues with aliasing?

 

Regards,

Rick

Edited by rickh, 25 March 2018 - 11:36 PM.

[mjr]

 

http://mjrnet.org/pi...php?sid=vl6180x

 

I don't think personally think these sensors are very good at plunger sensing either, frankly, but they're way better than the Sharp analog sensors, they're 3.3V compatible when you get one of those Pololu breakout boards, and the Pinscape software does have support specifically for them.

 

According to the spec the output does not exceed 2.5V.  I am bread-boarding an anti-log amp, perhaps with a gain of 1.32 to give it a full 3.3V FS.   

 

Rich - you're talking about the VL6180X, right?  If so, you're right about the sensor being a 2.8V device that needs voltage conversion, but you actually don't need to build anything yourself, unless you just want to as a project.  All of the breakout boards mentioned in the chapter (Pololu, Adafruit, Sparkfun) provide on-board voltage level shifters that will interface the sensor with a 5V Arduino or 3.3V KL25Z.

 

 

I can't recall if your software does an inversion of the input, if not I''ll make the output inverting.  

 

It doesn't exactly do inversion of the output at the voltage level, but there's a checkbox in the plunger sensor calibration that lets you reverse the orientation of the plunger readings.

 

 

Question- this device samples at 60Hz.  I don't know what the ADC sample rate on the Freescale is.  Do you think there will be issues with aliasing?

 

Again, assuming we're talking about the VL6180X, this device actually has a purely logic interface - there's no analog reading with it.  And 60 Hz is about right for it; the actual sample times are around 14ms.  Which, by the way, is part of why this isn't a great plunger sensor - you really want readings at about 400 Hz to keep up with the fastest motion of a plunger.

 

If you're talking about one of the Sharp analog distance sensors, though, that would be analog.  60Hz will be absolutely no problem to keep up with; that's glacially slow by the KL25Z's standards.  In the default 16-bit quantization, single-sampling mode that you'd usually use, it takes something like 10us to take an ADC reading (so you can read at about 100 kHz).  The KL25Z documentation claims that the shortest possible sample time is about 2us with all of the fast modes enabled (8-bit continuous mode using DMA transfers and some specific option register settings).   I was even able to get it pretty close (2.5us) in actual practice for the TSL1410R reader, but it takes some complex setup to make it happen.  If you only need 60Hz readings, nothing fancy will be required.

[mjr]

Rich - and if you actually were talking about the Sharp analog sensors, definitely let us know if you have any luck getting usable readings out of them.  I'm pretty skeptical about those because their raw signals are so low-res.  I suspect that adding an amp in front of it is going to make it way worse; you're probably better off using the raw signal and trying to do something about its non-linear response curve in software, since at least you won't have additional artifacts from an amplifier to try to subtract back out in that case.  I don't think that in the best case you can do much better than about 4dpi with those sensors.

[rickh]

 

 

http://mjrnet.org/pi...php?sid=vl6180x

 

I don't think personally think these sensors are very good at plunger sensing either, frankly, but they're way better than the Sharp analog sensors, they're 3.3V compatible when you get one of those Pololu breakout boards, and the Pinscape software does have support specifically for them.

 

According to the spec the output does not exceed 2.5V.  I am bread-boarding an anti-log amp, perhaps with a gain of 1.32 to give it a full 3.3V FS.   

 

Rich - you're talking about the VL6180X, right?  If so, you're right about the sensor being a 2.8V device that needs voltage conversion, but you actually don't need to build anything yourself, unless you just want to as a project.  All of the breakout boards mentioned in the chapter (Pololu, Adafruit, Sparkfun) provide on-board voltage level shifters that will interface the sensor with a 5V Arduino or 3.3V KL25Z.

 

 

I can't recall if your software does an inversion of the input, if not I''ll make the output inverting.  

 

It doesn't exactly do inversion of the output at the voltage level, but there's a checkbox in the plunger sensor calibration that lets you reverse the orientation of the plunger readings.

 

 

Question- this device samples at 60Hz.  I don't know what the ADC sample rate on the Freescale is.  Do you think there will be issues with aliasing?

 

Again, assuming we're talking about the VL6180X, this device actually has a purely logic interface - there's no analog reading with it.  And 60 Hz is about right for it; the actual sample times are around 14ms.  Which, by the way, is part of why this isn't a great plunger sensor - you really want readings at about 400 Hz to keep up with the fastest motion of a plunger.

 

If you're talking about one of the Sharp analog distance sensors, though, that would be analog.  60Hz will be absolutely no problem to keep up with; that's glacially slow by the KL25Z's standards.  In the default 16-bit quantization, single-sampling mode that you'd usually use, it takes something like 10us to take an ADC reading (so you can read at about 100 kHz).  The KL25Z documentation claims that the shortest possible sample time is about 2us with all of the fast modes enabled (8-bit continuous mode using DMA transfers and some specific option register settings).   I was even able to get it pretty close (2.5us) in actual practice for the TSL1410R reader, but it takes some complex setup to make it happen.  If you only need 60Hz readings, nothing fancy will be required.

 

MJR,

 

Sorry, should have specified- Sharp GP2Y0A51SK0F) It has an analog output and would be a good linear pot replacement if the output were linear and a bit higher amplitude.  BTW -I remember when you showcased the TSL1410R on youtube a few years ago.  When I got around to finally building my first table they were about as rare as chicken teeth, had to use a pot.    

[gtxjoe]

TSL1410R

10 In stock at Mouser
https://www.mouser.c...NSMA%2berfIlQ==

[mjr]

Sorry, should have specified- Sharp GP2Y0A51SK0F) It has an analog output and would be a good linear pot replacement if the output were linear and a bit higher amplitude.    

 

Rick - got it.  That could definitely be worth a try.  I haven't tried any of the triangulation sensors, only the older reflectivity sensors, which were terrible at being distance sensors.  Hopefully this will produce somewhat better results.  

 

But I still don't think amplifying the signal will work in your favor.  I assume your thinking about amplification is that it will improve sampling resolution by spreading out the voltage more uniformly over the full range of the ADC?  The thing is that there's not going to be any value at all in improving sampling resolution at the ADC, because the ADC already has tons more resolution than you'll be able to use.  The KL25Z ADC operates at 16-bit resolution in the slow modes - one part in 64K.  If you limit the voltage you're measuring to a range of 0-2.5V rather than 0-3.3V, that still gives you about one part in 50,000.  That's just the nominal precision, of course, and I'm sure the true accuracy is lower, but it's probably not lower by more than an order of magnitude.  So let's say one part in 5,000.  If you only use 2.5V of the 3.3V voltage range, you can still resolve one part in 3,750 over that range.

 

For comparison, the old reflectivity sensors could give you an accuracy of maybe one part in 5 (not 5,000, just 5) over a 10cm range.  The VL6180X gives you about 1 part in 20.  (Those nominally have millimeter precision, which would still only be 1 part in 100 over 10cm, but that's misleading.  From the error bars in the data sheet you can see that the actual accuracy is only about +-5 mm, which accords with my testing.) 

 

The data sheet for your sensor doesn't give error bars or accuracy claims, but I'm guessing it's not as good as the VL6180X.  Those use time-of-flight LIDAR, which should just be better.  So I expect the triangulation sensor is going to weigh in somewhere between the old reflectivity sensors and the VL6180X.  But let's say it's as good as the VL6180: even there, it's only 1:20, so the 1:3750 of the ADC on the KL25Z isn't going to be remotely the limiting factor in your resolving power.

 

The big downside of amplification is that you amplify the noise as well as the signal.  The old reflectivity sensors are ridiculously noisy; if you fed one of those into an amp you'd completely wipe out your signal and replace it with amplified noise.  The triangulation sensor might not be as bad, but it's still an analog signal coming out of it, so I bet it's still pretty noisy.  So given that you really don't need to increase the voltage for the sake of ADC resolving power, I suspect amplification is only going to make it worse.

 

 

BTW -I remember when you showcased the TSL1410R on youtube a few years ago.  When I got around to finally building my first table they were about as rare as chicken teeth, had to use a pot.   

 

Sorry you were too late on that!  It's really sad that they stopped making that sensor.  I've been keeping a look out for new alternatives coming on the market, but there must just be zero demand for anything like that any more.  I guess it's easier to make your bar-code readers out of 2D imagers now.

 

Keep in mind that there's the awesome AEDR-8300 alternative.

TSL1410R

10 In stock at Mouser
https://www.mouser.c...NSMA%2berfIlQ==

 

Interesting!  Anyone who wants one might want to snap those up post haste.  (Note that they did incorrectly list them as available like this about a year ago, but it seemed to be a glitch in their inventory system - so it might be best not to get your hopes up before you have a shipment in hand.)

Edited by mjr, 26 March 2018 - 10:10 PM.

[rickh]

 

Sorry, should have specified- Sharp GP2Y0A51SK0F) It has an analog output and would be a good linear pot replacement if the output were linear and a bit higher amplitude.    

 

Rick - got it.  That could definitely be worth a try.  I haven't tried any of the triangulation sensors, only the older reflectivity sensors, which were terrible at being distance sensors.  Hopefully this will produce somewhat better results.  

 

But I still don't think amplifying the signal will work in your favor.  I assume your thinking about amplification is that it will improve sampling resolution by spreading out the voltage more uniformly over the full range of the ADC?  The thing is that there's not going to be any value at all in improving sampling resolution at the ADC, because the ADC already has tons more resolution than you'll be able to use.  The KL25Z ADC operates at 16-bit resolution in the slow modes - one part in 64K.  If you limit the voltage you're measuring to a range of 0-2.5V rather than 0-3.3V, that still gives you about one part in 50,000.  That's just the nominal precision, of course, and I'm sure the true accuracy is lower, but it's probably not lower by more than an order of magnitude.  So let's say one part in 5,000.  If you only use 2.5V of the 3.3V voltage range, you can still resolve one part in 3,750 over that range.

 

For comparison, the old reflectivity sensors could give you an accuracy of maybe one part in 5 (not 5,000, just 5) over a 10cm range.  The VL6180X gives you about 1 part in 20.  (Those nominally have millimeter precision, which would still only be 1 part in 100 over 10cm, but that's misleading.  From the error bars in the data sheet you can see that the actual accuracy is only about +-5 mm, which accords with my testing.) 

 

The data sheet for your sensor doesn't give error bars or accuracy claims, but I'm guessing it's not as good as the VL6180X.  Those use time-of-flight LIDAR, which should just be better.  So I expect the triangulation sensor is going to weigh in somewhere between the old reflectivity sensors and the VL6180X.  But let's say it's as good as the VL6180: even there, it's only 1:20, so the 1:3750 of the ADC on the KL25Z isn't going to be remotely the limiting factor in your resolving power.

 

The big downside of amplification is that you amplify the noise as well as the signal.  The old reflectivity sensors are ridiculously noisy; if you fed one of those into an amp you'd completely wipe out your signal and replace it with amplified noise.  The triangulation sensor might not be as bad, but it's still an analog signal coming out of it, so I bet it's still pretty noisy.  So given that you really don't need to increase the voltage for the sake of ADC resolving power, I suspect amplification is only going to make it worse.

 

 

BTW -I remember when you showcased the TSL1410R on youtube a few years ago.  When I got around to finally building my first table they were about as rare as chicken teeth, had to use a pot.   

 

Sorry you were too late on that!  It's really sad that they stopped making that sensor.  I've been keeping a look out for new alternatives coming on the market, but there must just be zero demand for anything like that any more.  I guess it's easier to make your bar-code readers out of 2D imagers now.

 

Keep in mind that there's the awesome AEDR-8300 alternative.

TSL1410R

10 In stock at Mouser
https://www.mouser.c...NSMA%2berfIlQ==

 

Interesting!  Anyone who wants one might want to snap those up post haste.  (Note that they did incorrectly list them as available like this about a year ago, but it seemed to be a glitch in their inventory system - so it might be best not to get your hopes up before you have a shipment in hand.)

 

I think Mike is right about the availability of those parts, Mouser is notorious for listing items in stock when they are not.  I'm going to play with this Sharp device and if it works good I'll integrate the interface into my existing board.  

[rickh]

Update-  I attempted to linearize the output of the Sharp GP2Y0A51 Analog distance Sensor using an anti-log amplifier.   Long story short- failure.  A waste of a rainy Saturday afternoon.

[marc9]

Hi, is the DOF Tester application still working? I get an exception under Windows 7. I followed the instructions (Path etc.). Then copied the content of the zip file direct into the c:\ DirectOutput folder and tried again. Same result. I use the DOF R3++ version from march. The KL25Z/PInscape Controller works fine on this pc.

[mjr]

Hi, is the DOF Tester application still working? I get an exception under Windows 7. I followed the instructions (Path etc.). Then copied the content of the zip file direct into the c:\ DirectOutput folder and tried again. Same result. I use the DOF R3++ version from march. The KL25Z/PInscape Controller works fine on this pc.

The problem is that the program has to be compiled against the exact version of DOF you're using.  I should probably just remove the prebuilt binary and only distribute it as source, or maybe merge it into the DOF build itself so that it's always built with each DOF release.

[marc9]

 

Hi, is the DOF Tester application still working? I get an exception under Windows 7. I followed the instructions (Path etc.). Then copied the content of the zip file direct into the c:\ DirectOutput folder and tried again. Same result. I use the DOF R3++ version from march. The KL25Z/PInscape Controller works fine on this pc.

The problem is that the program has to be compiled against the exact version of DOF you're using.  I should probably just remove the prebuilt binary and only distribute it as source, or maybe merge it into the DOF build itself so that it's always built with each DOF release.

 

Thanks for the reply.

[Cameron]

OK I am having a weird problem only on my actual cabinet PC.

When I go to run the Pinscape setup software and I click on the "Buttons" button, I get an unhandled exception error

If I take it to another PC, I don't get the error.

 

Another artifact is that on my front-end, it doesn't recognize the Pinscape button presses. JoyToKey does and other utilities see it as a DirectX joystick, but not Pinup Popper/System. I think this is related, but have no idea what to do to resolve the exception.

 

Any ideas?

[mjr]

OK I am having a weird problem only on my actual cabinet PC.

When I go to run the Pinscape setup software and I click on the "Buttons" button, I get an unhandled exception error

If I take it to another PC, I don't get the error.

 

Do you get any other details in the error box?  C# errors boxes usually give you a stack trace, or at least some code location information.  Any other details it's displaying would be helpful in diagnosing it.

[Cameron]

Yeah when I get back to the other machine I'll replicate it and give the details. Thanks!!!!! 

I have the Expansion board complete and am about 50% done with the power board. Starting to get excited hahahahaha

[Cameron]

OK here is the detail text from the Unhandled Exception:

 

See the end of this message for details on invoking 

just-in-time (JIT) debugging instead of this dialog box.

 

************** Exception Text **************

System.NullReferenceException: Object reference not set to an instance of an object.

   at PinscapeConfigTool.ButtonStatus.statusTimer_Tick(Object sender, EventArgs e)

   at System.Windows.Forms.Timer.OnTick(EventArgs e)

   at System.Windows.Forms.Timer.TimerNativeWindow.WndProc(Message& m)

   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)

 

 

************** Loaded Assemblies **************

mscorlib

    Assembly Version: 4.0.0.0

    Win32 Version: 4.7.3101.0 built by: NET472REL1LAST_B

NET/Framework64/v4.0.30319/mscorlib.dll

----------------------------------------

PinscapeConfigTool

    Assembly Version: 1.0.6604.20506

    Win32 Version: 1.0.0.0

Downloads/Pinscape/PinscapeConfigTool.exe

----------------------------------------

System.Windows.Forms

    Assembly Version: 4.0.0.0

    Win32 Version: 4.7.3056.0 built by: NET472REL1

Net/assembly/GAC_MSIL/System.Windows.Forms/v4.0_4.0.0.0__b77a5c561934e089/System.Windows.Forms.dll

----------------------------------------

System

    Assembly Version: 4.0.0.0

    Win32 Version: 4.7.3056.0 built by: NET472REL1

Net/assembly/GAC_MSIL/System/v4.0_4.0.0.0__b77a5c561934e089/System.dll

----------------------------------------

System.Drawing

    Assembly Version: 4.0.0.0

    Win32 Version: 4.7.3056.0 built by: NET472REL1

Net/assembly/GAC_MSIL/System.Drawing/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll

----------------------------------------

System.Configuration

    Assembly Version: 4.0.0.0

    Win32 Version: 4.7.3056.0 built by: NET472REL1

Net/assembly/GAC_MSIL/System.Configuration/v4.0_4.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll

----------------------------------------

System.Core

    Assembly Version: 4.0.0.0

    Win32 Version: 4.7.3101.0 built by: NET472REL1LAST_B

Net/assembly/GAC_MSIL/System.Core/v4.0_4.0.0.0__b77a5c561934e089/System.Core.dll

----------------------------------------

System.Xml

    Assembly Version: 4.0.0.0

    Win32 Version: 4.7.3056.0 built by: NET472REL1

Net/assembly/GAC_MSIL/System.Xml/v4.0_4.0.0.0__b77a5c561934e089/System.Xml.dll

----------------------------------------

System.IO.Compression

    Assembly Version: 4.0.0.0

    Win32 Version: 4.7.3056.0 built by: NET472REL1

Net/assembly/GAC_MSIL/System.IO.Compression/v4.0_4.0.0.0__b77a5c561934e089/System.IO.Compression.dll

----------------------------------------

System.IO.Compression.FileSystem

    Assembly Version: 4.0.0.0

    Win32 Version: 4.7.3056.0

Net/assembly/GAC_MSIL/System.IO.Compression.FileSystem/v4.0_4.0.0.0__b77a5c561934e089/System.IO.Compression.FileSystem.dll

----------------------------------------

WindowsBase

    Assembly Version: 4.0.0.0

    Win32 Version: 4.7.3101.0 built by: NET472REL1LAST_B

Net/assembly/GAC_MSIL/WindowsBase/v4.0_4.0.0.0__31bf3856ad364e35/WindowsBase.dll

----------------------------------------

 

************** JIT Debugging **************

To enable just-in-time (JIT) debugging, the .config file for this

application or computer (machine.config) must have the

jitDebugging value set in the system.windows.forms section.

The application must also be compiled with debugging

enabled.

 

For example:

 

<configuration>

    <system.windows.forms jitDebugging="true" />

</configuration>

 

When JIT debugging is enabled, any unhandled exception

will be sent to the JIT debugger registered on the computer

rather than be handled by this dialog box.

[mjr]

@Cameron - that narrows it down, but not enough to see what's going on.  Here's a debug build that should give a more precise location in the error message:

 

http://mjrnet.org/pi...ug_20180519.zip

 

That only includes the .exe - it should be enough to replace your existing .exe with that one and try running it again.  I just need the "exception text" part at the very top of the error message with the stack trace.

[Cameron]

OK I'll try that one out....

I have been working on it today to diagnose some things as well... 

 

Started in safe mode and things work OK.

Turned off all services that weren't MS and thing still have issues.

Have been trying to figure out which ones are causing it to do this...

 

Thanks!

 

Cameron

[JLPicard001]

I seem to have a problem with my new KL25Z.  Today I soldered on the header pins and for the first time I thought I'd hook up my first button to test it out.  I used pins J9 14 and 13 to test the button.  When I attached my KL25Z to my computer, it noticed the hardware and I got the familiar Windows beep.  I went to Set up USB Game Controllers control panel and it had Pinscape Controller listed.  I double clicked the entry.  I tested the button and button 8 lit up on the control panel display.  All good.

 

I then went to Visual Pinball (995) and assigned Left Flipper to button 8.  I then fired up a game, and that's when things got weird.  I started getting odd flashings on the KL25Z, I didn't notice the patterns, but my computer was giving me "hardware connected, hardware disconnected" beeps, and after about five seconds off all this, it stopped and my KL25Z began to flash the onboard LED: four yellow flashes about a second apart, off for about three seconds then repeats.

 

USB Game Controllers no longer sees it.  I tried reflashing the firmware and it worked just fine.  Same results.  Reset button on board does nothing either.

 

Any ideas?

[mjr]

I seem to have a problem with my new KL25Z.  Today I soldered on the header pins and for the first time I thought I'd hook up my first button to test it out.  I used pins J9 14 and 13 to test the button.  When I attached my KL25Z to my computer, it noticed the hardware and I got the familiar Windows beep.  I went to Set up USB Game Controllers control panel and it had Pinscape Controller listed.  I double clicked the entry.  I tested the button and button 8 lit up on the control panel display.  All good.

 

I then went to Visual Pinball (995) and assigned Left Flipper to button 8.  I then fired up a game, and that's when things got weird.  I started getting odd flashings on the KL25Z, I didn't notice the patterns, but my computer was giving me "hardware connected, hardware disconnected" beeps, and after about five seconds off all this, it stopped and my KL25Z began to flash the onboard LED: four yellow flashes about a second apart, off for about three seconds then repeats.

 

USB Game Controllers no longer sees it.  I tried reflashing the firmware and it worked just fine.  Same results.  Reset button on board does nothing either.

 

The yellow flash pattern sounds like it's not able to connect to USB, which is consistent with what you're seeing on the Windows side.  Here's a list of the flash patterns and what they mean:

 

http://mjrnet.org/pi...id=statusLights

 

The first thing I'd try is disconnecting all wires from the KL25Z.  Everything - the USB cable, all of your button wires, any other wires you've attached.  Then try plugging it back into USB.  You might try a reboot of the PC before plugging in the USB as well to get everything reset to a clean baseline.

 

Also make certain you're using the USB port labeled "KL25Z", not the one labeled "OpenSDA".  The OpenSDA port doesn't actually connect to the KL25Z - it connects to a whole separate microcontroller on the board whose only purpose in life is to download firmware onto the KL25Z.

 

If it still won't connect, you might want to carefully inspect your soldering to make sure that you didn't accidentally have some solder stray across pads and short a couple of pins together.  Random shorted pins can cause weird behavior including intermittent resets, or can just outright damage the device.

 

I also wouldn't recommend using the "Set up USB Game Controllers" control panel for doing much of anything, because it has that heinous History Destroyer Button - the one labeled Calibrate that most people find themselves irresistibly compelled to press even though it will screw up everything if you do.  That control panel also just doesn't give you very much information about what's going on or control over settings.  The place to go for all of your setup needs is the Pinscape Config Tool, which you can find here:

 

http://mjrnet.org/pi.../swversions.php

[JLPicard001]

Thanks for response MJR.

I used the Pinscape Config tool to flash the card.  The problem is that I never can get past Step 5: Plug in Joystick Port.  I tried the USB Game Controllers after finding that in your first guide from 2014, section: Wire the cabinet button inputs.  This was while the PC/KL25Z was still communicating over the USB.  All I did there was verify that my single hooked up button was working, it was showing up as button 8.

 

I just now reattached the USB to the PC via the KL25Z connector.  The PC again gave me the 'found hardware' responding beeps, and the KL25Z began to give me this indicator:

 

Two short red flashes in rapid succession every couple of seconds: the USB connection to the PC was broken. This can happen if the USB cable is physically unplugged or the connection is broken at a software level. Software disconnections can happen due to software errors, and can also happen if the Windows USB drivers intentionally disconnect.

 

After it flashes as above, it then goes into the flashing yellow cycles I mentioned above.