734 replies to this topic

[mjr]

 

Kudos on some well documented code and my apologies if I am reading it incorrectly.'

 
This snippet seems to be saying that if the sampled position is less than the previous position, and the previous position was greater than 0, and later that we have crossed the plunger's rest position then we are in a firing event.  I don't see the requirement that the distance between the znew and z0 must be greater than some threshold.  This is the check you perform to see if a firing event occurs during a "highresscan".
 
This looks in contrast to the condition for any other time:

if (!firing && cfg.d.plungerEnabled && z >= JOYMAX/6)

Where it seems you require it be pulled back at least 1/6 of the travel (1/2"). Am I reading this correctly? It seems during the "highresscan" only a small amount of noise could trigger the firing event.

 

That's a good catch - I think you're right.  That check for crossing the zero point probably needs to have a distance threshold from previous readings along the same lines as the others.  I'll take a closer look and make a testing version for you to try out.

 

I just posted a new version with this change, and I also added some averaging to the analog readings.  Hopefully the combination of the two will solve the spurious firing problem!  Let me know what you find when you have a chance to test it.

 

http://mbed.org/user...ape_Controller/

 

 

You're probably right about my missing a few outliers visually on the windows output, however the oscilloscope noise now (since the GND wire addition) seems capped to 50mV on a 3.3V full scale signal. That's not bad. 

 

I hadn't done the math before, but that level of noise is almost certainly enough to account for the spurious firing events with the missing threshold test in the old code.  50mV is about 1.5% of the overall 0-3.3V range; in terms of travel distance, that translates to about 1.25mm.  The quantization level I use on the CCD is 1 part in 160, which is 0.6% or .5mm.  So the 50 mV noise level is definitely in the range where I've been assuming a pretty noiseless signal.  That's not a completely safe assumption even with the CCD, since even there you can get fluctuations of a few pixels plus or minus because the shadow edge on the sensor is fuzzy.  So this was a good thing to fix even for the CCD.

[Spektre]

Kudos on some well documented code and my apologies if I am reading it incorrectly.'
 
This snippet seems to be saying that if the sampled position is less than the previous position, and the previous position was greater than 0, and later that we have crossed the plunger's rest position then we are in a firing event.  I don't see the requirement that the distance between the znew and z0 must be greater than some threshold.  This is the check you perform to see if a firing event occurs during a "highresscan".
 
This looks in contrast to the condition for any other time:

if (!firing && cfg.d.plungerEnabled && z >= JOYMAX/6)

Where it seems you require it be pulled back at least 1/6 of the travel (1/2"). Am I reading this correctly? It seems during the "highresscan" only a small amount of noise could trigger the firing event.

 
That's a good catch - I think you're right.  That check for crossing the zero point probably needs to have a distance threshold from previous readings along the same lines as the others.  I'll take a closer look and make a testing version for you to try out.

 
I just posted a new version with this change, and I also added some averaging to the analog readings.  Hopefully the combination of the two will solve the spurious firing problem!  Let me know what you find when you have a chance to test it.
 
http://mbed.org/user...ape_Controller/
 
 

You're probably right about my missing a few outliers visually on the windows output, however the oscilloscope noise now (since the GND wire addition) seems capped to 50mV on a 3.3V full scale signal. That's not bad.

 
I hadn't done the math before, but that level of noise is almost certainly enough to account for the spurious firing events with the missing threshold test in the old code.  50mV is about 1.5% of the overall 0-3.3V range; in terms of travel distance, that translates to about 1.25mm.  The quantization level I use on the CCD is 1 part in 160, which is 0.6% or .5mm.  So the 50 mV noise level is definitely in the range where I've been assuming a pretty noiseless signal.  That's not a completely safe assumption even with the CCD, since even there you can get fluctuations of a few pixels plus or minus because the shadow edge on the sensor is fuzzy.  So this was a good thing to fix even for the CCD.

Cool beans. I hop to et to it tonight, but if not tomorrow. I'm trying to find a way to better the noise figure.

[Spektre]

Not a good result today.

 

Tried the new software, same auto firing.

 

So I tried the board on my laptop.  No auto firing.  So I tried the board on my laptop with the board in position in an ON cab.  No autofiring.

 

I went to the mbed complier and commented out the two places that appear to enter an auto fire state.  (I only found 2 statements that set firing = 1).  Even with that commented out it still auto fired in the cabinet,  Very strange.

 

Pulling the plunger back WOULD stop it, as would disabling the Mechanical Plunger on the table.

 

------

 

The result are screwy enough I wiped the cabinet's HDD clean and am reinstalling everything from scratch.  This takes a bit, but should leave conflicting software out of the mix.

 

1.  How many places does autofiring get set?  (I found 2, did I miss any?) 

2.  The ball gets fired at a very high velocity.  I KNOW the noise isn't pulling the plunger back very far, nor do I see the "bounce" animation the code says I should see for this. (Oscillation after the release) .  The plunger remains completely steady

[mjr]

 

Tried the new software, same auto firing.

So I tried the board on my laptop.  No auto firing.  So I tried the board on my laptop with the board in position in an ON cab.  No autofiring.

 

 

Okay, that would seem to eliminate the firmware as the source of the problem.  If the identical board with the identical firmware works on one PC and doesn't work on the other PC, the problem is probably the PC.

 

The result are screwy enough I wiped the cabinet's HDD clean and am reinstalling everything from scratch.  

 

When you get it set back up, see if that changes anything.  If it's still not working right, see if you can figure out what's different between the laptop and PC.

Edited by mjr, 06 June 2015 - 06:57 PM.

[Spektre]

Some good/bad news and some bad news.

 

The good/bad news is the freshly installed system is not exhibiting the out of proportion to noise variation in the reported plunger location.  The fault must have been in some poor software configuration on my system.  Sorry to have had you troubleshoot my system.

 

The bad news is, now I have a new problem, though I think I know the reason for this one.

 

Upon putting the PC through a restart the board stops normal operation and begins the 2 quick red flashes indicating a USB fault has occurred.  I have removed all the other added hardware from my filtering experiments, but a 10uF capacitor still remains between the 5V pin and GND.  My guess is that during a computer reboot you are depending on a power cycle to reset the hardware, and the 10uF cap is enough to hold the board powered through the reboot.

 

Can you confirm that if USB comms is lost (as in during a restart) you require a power reset to the board?  If so a solution is simply to remove the 10uF cap, and live with slightly dirtier USB power.  If it is an easy method to reestablish lost USB comms is software, that would be a "better" method as it would allow for a more stable power source to be used.

 

Thanks in advance.,

[mjr]

Some good/bad news and some bad news.

 

The good/bad news is the freshly installed system is not exhibiting the out of proportion to noise variation in the reported plunger location.  The fault must have been in some poor software configuration on my system.  Sorry to have had you troubleshoot my system.

 

The bad news is, now I have a new problem, though I think I know the reason for this one.

 

Upon putting the PC through a restart the board stops normal operation and begins the 2 quick red flashes indicating a USB fault has occurred.  I have removed all the other added hardware from my filtering experiments, but a 10uF capacitor still remains between the 5V pin and GND.  My guess is that during a computer reboot you are depending on a power cycle to reset the hardware, and the 10uF cap is enough to hold the board powered through the reboot.

 

Can you confirm that if USB comms is lost (as in during a restart) you require a power reset to the board?  If so a solution is simply to remove the 10uF cap, and live with slightly dirtier USB power.  If it is an easy method to reestablish lost USB comms is software, that would be a "better" method as it would allow for a more stable power source to be used.

 

Glad to hear there's at least one bit of improvement.  

 

The USB connection *should* be retried when lost, so ideally it should come back on its own, but rebooting the board is definitely the best way to get things out of bad states.  One thing you might want to try before removing the cap is the manual reset button on the KL25Z.  Don't disconnect anything, just push and hold the reset button for a couple of seconds to give Windows a chance to reset its side of the connection, then release it and see if it manages to connect.  If that does the trick, removing the cap is probably a good thing to try next.  

[Spektre]

Man, this just isn't working well here.

 

So, I removed the cap and the behavior listed above did not change.  When the PC goes through a reboot cycle, and USB comms drop, it will not reestablish communication until a hard power (unplugging and replugging the USB cable or powering off the cabinet) is completed.  I decided this was a livable state as this rebooting should not occur frequently.  In general, the cabinet is powered on and the machine boots to PinballX at which time it played and not dropped back into Windows until shutdown and subsequently power off.

 

Unfortunately, the board is frequently dropping out of normal operation and going into the 2 flashing red blinks mode even during normal play.  I have no idea what may be causing this.  The only way to clear it is to pull the cord and reinsert (Pushing the reset button also clears the error but puts the board back into "plunger uncalibrated" mode.

 

Is anyone else seeing unusual dropping out of normal operation?

[mjr]

Is anyone else seeing unusual dropping out of normal operation?

 

Sorry it's not working.  My only first-hand data point is that mine has been rock solid.

 

It *could* be a compatibility issue with your motherboard.  The mbed KL25Z USB driver had some problems when I first started on this where it basically didn't work at all with USB 3.0 ports.  It was a known problem at the time that lots of other people ran into.  I spent a long time tracing through the drivers and found that the problem had to do with protocol peculiarities exhibited by my motherboard.  I fixed it for *my* motherboard, which uses a pretty common Intel chip set, but it wouldn't surprise me if it's not truly fixed for all USB 3.0 hosts - there could well be other similar problems with other motherboards.  The behavior you're seeing is actually pretty similar to what I ran into with the old mbed USB stack - random failure to connect at boot-up and random disconnects.

 

Have you tried a USB 2.1 hub?  That's a solution that seems to work for some people with the VirtuaPin kit, which is also based on the KL25Z and also has mysterious problems with some USB hosts. Their problems are usually ascribed to power handling issues, but I suspect that's not really the root cause - I suspect that they have the same (or a similar) software issues with USB 3 compatibility that I ran into with the mbed USB stack.  USB 3 just seems tricky for microcontroller devices to get right.  Anyway, a hub that talks *only* USB 2.1 seems to help with some of these compatibility issues.  USB 2.1 seems to have been easier to get right on the device side.

 

This would be a horrible hack, but as a last resort you *could* build some external hardware that would let the on-board software on the KL25Z trigger a hard reset.  The KL25Z's reset line isn't accessible from software in the default hardware configuration, but there's a pin-out for it on one of the jumper pads.  You could set up some external wiring that would tie the reset line to a GPIO port, allowing the firmware to trigger a hard reset by writing the tied GPIO port.  The software could use a little watchdog timer that executes the reset when the USB port has been disconnected for some suitable interval.

 

By the way, you *shouldn't* be losing calibration data after a hard reset if you're just pushing the button.  Pushing and holding the button while unplugging and replugging power *does* clear the flash memory and launch the boot loader to re-load new firmware, but just pushing and releasing the button without power cycling should be preserving the flash contents.  The calibration data lives in flash, so it shouldn't be lost across a power cycle or simple hard reset.

Edited by mjr, 26 June 2015 - 12:05 AM.

[Spektre]

Interesting as this IS a constant for me.   If the board has gone into the double flashing red mode and I try to clear it via the reset button, I will ALWAYS go to the yellow blue mode.  At first I thought something associated with the crash must be messing up the flash memory but then noted that even when in yellow/blue, a power cycle to the board restored greed/blue. 

[mjr]

Interesting as this IS a constant for me.   If the board has gone into the double flashing red mode and I try to clear it via the reset button, I will ALWAYS go to the yellow blue mode.  At first I thought something associated with the crash must be messing up the flash memory but then noted that even when in yellow/blue, a power cycle to the board restored greed/blue. 

 

No idea what's going on with that - it should be exactly the same path through the startup code on a power cycle or reset via the button, so it should be exactly the same behavior.  The flash memory must be preserved across the reset if you can get it back later by doing a power cycle, so there must be something different about the software environment in the reset button case that I'm not aware of.  (And which apparently doesn't affect my version of the board, as I don't see the different behavior.)

[hopvision]

First off, I want to say thanks to mjr and everyone else working to innovate.  My experience building, configuring and now enjoying my cabinet has been pretty amazing.

 

One of the things that I haven't ironed out as of yet is nudging.  I have been trying for two weeks to tune my sidewinder freestyle pro to my liking and have had terrible luck so far.  I couldn't manage to calibrate it properly between windows, dxtweak2 and VP 9.9.1 to make it nudge realistically.  Either it was throwing the ball all over the place or it was nudging only one direction or it was immediately tilting the machine (or tilting at random).  Sunday night, I got pissed enough to really dig into this thread and decided to order the freescale board from Amazon.  

 

Fast forward to today.  I followed the excellent instructions mjr has provided and was able to update the firmware and install the Pinscape bin on the card.  I plugged it in and checked the windows joystick test to see it move.  It does appear that the accelerometer is functioning and I can see subtle movements when I bump the cabinet in each direction.  It isn't flying around, but it's moving 1-2x the width of the crosshair with firm nudges.  I then configured VP 9.9.1 with the settings suggested (1000 gains, plunger disabled since I'm not using z-axis for anything).  I fired up the flat accel test table and wasn't really able to nudge the ball any direction but up.  Even after adjusting, it doesn't seem to nudge on the X-Axis, but it moves on the Y-Axis no matter which direction I nudge from.

 

Continuing on, I loaded a few tables.  CFTBL and MM were my first tests.  Loading up the tables and starting a game, a simple nudge in any direction would fire the ball and immediately tilt.  I tried bringing gain down in steps all the way to 100 with no luck (exiting VP and closing the table each time).  Commenting out the nudge code in the tables (tiltswitch and sensitivity) would allow me to play, but I can still really only seem to nudge up.  If I do windows calibration on the pinscape controller, the ball is all over the place but able to be nudged directionally, but as soon as I set it back to default, nudging up occurs with a bump in any direction.  I have reset dxtweak and windows calibration to defaults.  So frustrating.

 

Does anyone know why the hell my cabinet will only nudge up?

 

This brings me to a few other questions...

 

Assuming I can fix the directionally challenged nudge issue...  Do I need a custom nudgeplugin.vbs with specific settings to override the tables?   Do I need to edit core.vbs to change the code?  Is it possible that I have accumulated some custom nudge code somewhere that's affecting me?  Will I need to override all of the hundreds of tables I've installed to make nudge work?  Am I just missing something simple?

 

Sorry for all of the questions.  Nudging just does not seem to work for me, and I'm starting to lose my mind.

 

EDIT:  Wanted to add that the z-axis is jumping around a bit.  There are some fans and other stuff in the cabinet, and I assume the slight vibration from those are the likely culprit.  If I set plunger to z-axis, the plunger dances up and down pretty good.  Additionally, I can disable the Y-Axis altogether and it still nudges up.  I can switch the X-Axis to Y-Axis and it still nudges up.  This makes no sense.

Edited by hopvision, 29 July 2015 - 03:33 AM.

[WiiMoritz]

I uploaded a video showing my "Double" DIY Plunger (analogic and digital together).

It's working pretty nice.

I am using a gamecube controller.

 

https://youtu.be/W1pYAMTkm1I

[connorsdad]

I'm selling the Freescale KL25Z board and the TSL141OR board used in this project if anyone is interested, £30 + postage, UK only. I went a different way so these are surplus to my requirements.

Sent from my SM-N9005 using Tapatalk

[cyril92]

Hi mjr, I bought a KL25Z and a CCD, but the CCD is not already plugged and soldered. So I only tried to plug the KL25Z for the nudge.

 

I have few questions :

Do I have to calibrate the pinscape controller in Windows and How ? or Can I try something else ?

My Card is blinking Yellow/Green (of course I didn't make the calibration) : can I let it like that, and nudge will work correctly ?

When the ball is waiting for shoot, the ball is trembling in VP. Is it always a problem of no calibration ?

 

I want to precise that I unchecked the plunger in the pinscape config tool, and I put in VP (991) the values written in your tutorial.

 

Thanks in advance.

Cyril.

[mjr]

Hi mjr, I bought a KL25Z and a CCD, but the CCD is not already plugged and soldered. So I only tried to plug the KL25Z for the nudge.

 

I have few questions :

Do I have to calibrate the pinscape controller in Windows and How ? or Can I try something else ?

My Card is blinking Yellow/Green (of course I didn't make the calibration) : can I let it like that, and nudge will work correctly ?

When the ball is waiting for shoot, the ball is trembling in VP. Is it always a problem of no calibration ?

 

I want to precise that I unchecked the plunger in the pinscape config tool, and I put in VP (991) the values written in your tutorial.

 

The nudge feature is self-calibrating, so there's nothing to calibrate manually apart from the "gain" values in VP.  

 

Yellow/Green means everything is working fine.  If you turned off the plunger in the config tool, it actually should change to Blue/Green, but the only difference between Yellow/Green and Blue/Green is that Yellow/Green means that plunger calibration is pending.  Either calibrating the plunger or turning it off removes the need to calibrate it and thus changes to Blue/Green.

 

If the ball is trembling when the cabinet is undisturbed, your gain is turned up too high in VP.  Change to a lower value.  If you're using VP 10, you have to reduce the values by a factor of either 10 or 100, I don't remember which.  E.g., if your VP 9 gain works at about 1000 (where I have mine set), the VP 10 gain has to be changed to either 100 or 10.  You just need to experiment to find the right level.

 

Also, if you haven't nailed down the KL25Z (usually by fastening it to the cabinet floor with spacers and screws), you might just be picking up spurious vibration from the board being unsecured.  The accelerometer is very sensitive, so it'll pick up a fair amount of jitter from the physical vibration of the board if it's not securely attached to something.

[cyril92]

Hi mjr, and thank you for your answer.

 

First, I don't know if you remember, but it was me who asked you the favour to translate your document in french, in order to let french people enjoy your job !

So now, few of us (french pincab community) have installed your system, and we have quite a good experience on it.

Me I'm a newbie, because I've just begun to make my own pincab, and I installed the card for nudging only yesterday.(I'm waiting for time to solder the plunger part)

 

Anyway, We experienced also some dysfunctions, as discussed in this topic, but I think I found an 'error' in your pinscape configtool.

 

The problem : I went in the config tool in order to uncheck the 'enable plunger sensor' functionnality, and applied it. But each time I restarted my PC, the led went yellow/green, And I saw that the 'enable plunger sensor' was checked again (not saved so).

The solution : I unckecked the funtionnality, and applied. Then Checked and applied again, and unchecked/applied last time, as it is my configuration. And now, I have no problem of yellow/green blinking again.

 

So I think that when your are configuring the first times, something is not saved.

 

Is it something that you can try and check by your side ?

 

Thanks a lot for your work, I really like what you did, and I am happy to help and promote your work in our french community.

 

Cyril.

 

P.S : I forgot to check 'enable nudge filter' in VP, that's why the ball was trembling ...

Edited by cyril92, 28 October 2015 - 10:15 AM.

[shadowshd]

If I can give some more informations, we are discussing this yellow/green state LED after a reboot on a french pincab forum, with Cyril.

 

I'm using a KL25Z with a CCD, and followed your great tutorial to install it in my cab.

By the way, thank you for your great job

 

What I've done to always have the blue/green state LED on boot/reboot is to flash the KL25Z four or five times in a row with the DEBUG-APP_PEmicro_v108.sda instead of the MSD-Debug-FRDM-KL25Z_v114.sda as recommanded in the tutorial.

 

I don't know what are the differences between sda files, but today it's the only way I found to solve this issue.

 

When I'll have some time, I'll reflash my KL25Z with the MSD-Debug.sda file, just to check.

 

Thank you again

 

++

[mjr]

First, I don't know if you remember, but it was me who asked you the favour to translate your document in french, in order to let french people enjoy your job !

 

Thanks again for doing that!

 

 

The problem : I went in the config tool in order to uncheck the 'enable plunger sensor' functionnality, and applied it. But each time I restarted my PC, the led went yellow/green, And I saw that the 'enable plunger sensor' was checked again (not saved so).

The solution : I unckecked the funtionnality, and applied. Then Checked and applied again, and unchecked/applied last time, as it is my configuration. And now, I have no problem of yellow/green blinking again.

 

So I think that when your are configuring the first times, something is not saved.

 

I'll take a look at the code and see if I can spot the problem.  That does sound like there's an error in the update logic somewhere.

 

 

What I've done to always have the blue/green state LED on boot/reboot is to flash the KL25Z four or five times in a row with the DEBUG-APP_PEmicro_v108.sda instead of the MSD-Debug-FRDM-KL25Z_v114.sda as recommanded in the tutorial.

 

I don't know what are the differences between sda files, but today it's the only way I found to solve this issue.

 

Hmm... I don't *think* that should make any difference to the blinking light behavior, but maybe I'm missing something.  The boot loader actually doesn't run on the "KL25Z" per se.  The KL25Z board actually has two CPUs - the main KL25 (ARM Cortex M0+) CPU where the Pinscape software runs, and a secondary K20 (Cortex M4) CPU that runs the boot loader.  The two are quite isolated; there's no shared memory or shared flash, just a serial data connection that the secondary CPU uses to send commands to the main CPU to update its flash contents.  The boot loader software is never copied onto the main CPU, and never interacts in any way with the Pinscape software other than to copy its bytes into the main CPU's flash when you go through the drag-and-drop update process in Windows.  So apart from the drag-and-drop process, the version of the boot load .sda that's loaded shouldn't make any difference at all - when the Pinscape software is running, the boot loader just sits there quietly on on that other CPU doing nothing.  But maybe there's some subtle interaction with the flash access that I'm not aware of.

 

I'm actually kind of surprised that you can get the mbed software to work at all with the 108.sda boot loader.  Everything I've read says you have to update to 114 before you can use the mbed tool chain.  But I haven't actually tried the older version; I just followed the advice about installing the 114.sda version before doing anything else, so that's the only version I've even tried it with.  Evidently the older software does work, at least in some setups!

[mjr]

 

The problem : I went in the config tool in order to uncheck the 'enable plunger sensor' functionnality, and applied it. But each time I restarted my PC, the led went yellow/green, And I saw that the 'enable plunger sensor' was checked again (not saved so).

The solution : I unckecked the funtionnality, and applied. Then Checked and applied again, and unchecked/applied last time, as it is my configuration. And now, I have no problem of yellow/green blinking again.

 

So I think that when your are configuring the first times, something is not saved.

 

 

I'll take a look at the code and see if I can spot the problem.  That does sound like there's an error in the update logic somewhere.

 

I took at look, and sure enough, there's an error in the code that saves the data.  It uses a checksum to make sure that the config data was correctly saved, and there was an error in the order of events in calculating that.  Going through the save code twice or more in a row is enough to get everything in sync, which is why your trick of saving three times worked.  I've fixed it for the next update (which I want to test a little more before publishing, since it also has a bunch of work related to the Expansion Board project I've been working on).

[shadowshd]

Thank you MJR

 

++