734 replies to this topic

[Mace]

Thanks again Mike

 

I'll try rev #53 to #55 in a few minutes.

 

I think like you : there must be something somewhere that breaks USB connection, so your idea of going reverse to put our fingers on the culprit is very clever.

 

Also I can revert back to rev #33 whenever I want, like Mace, without any issue.

 

One more thing... Yesterday when I tested a rev (can't remember which one), I had compilation errors but the bin was although generated.

I put it in my KL, and one of my two relay boards connected to the KL, started to switch on and off one of the relays constantly...

I just put that on the generated errors during compilation, but in case, it may have some importance for you to know.

 

Will edit and feedback ASAP.

 

 

Edit : OK Mike, rev #61 (USBHAL_KL25Z_ stall fixes) is the culprit.

 

I started from #64 to #61 -=> unknown device.

#60 -=> working flawlessly, as good as #33 

 

I stopped at #60, I'm sure previous revisions will work as well

 

Now waiting for further instructions 

 

++

 

Yep, I concur with shadowshd's finding too, I built the lot and they all work up to v60, then from v61 on the issue occurs - looks like we have the culprit

[mjr]

Edit : OK Mike, rev #61 (USBHAL_KL25Z_ stall fixes) is the culprit.

 

I started from #64 to #61 -=> unknown device.

#60 -=> working flawlessly, as good as #33 

 

I stopped at #60, I'm sure previous revisions will work as well

 

Yep, I concur with shadowshd's finding too, I built the lot and they all work up to v60, then from v61 on the issue occurs - looks like we have the culprit 

 

Hooray!  Finally found it!

 

Thanks so much for your patience trying all of these changes.

 

I'll post a new update with the 60->61 changes removed and everything else retained, so that we can make sure there's nothing else in the 62->64 changes causing separate problems.  I'll let you know when that's ready.

 

I'm going to have to look at the 60->61 changes again and determine why I added them in the first place.  Most of the USB fixes in this batch of updates came from specific problems I found in testing that needed to be fixed, while a few came from studying the hardware documentation rather than empirical testing.  I think the 60->61 changes are in the second category, and if that's true then I'll just ditch them entirely.  If they were required to fix some actual problem, then I'll have to figure out another way to fix the problem that doesn't break it on everyone else's machine!

[mjr]

Shadowshd and Mace, my apologies, but I have three more versions for you to try!

 

All still on the Pinscape_Controller_v1 fork.

 

#65 - keeps all of the other changes but tries to FIX the new stall handling that we now know breaks things on your machines

 

#66 - keeps all of the other changes but removes SOME of the new stall handling, specifically the part that I think is most likely to cause the connect problem

 

#67 - keeps all of the other changes but removes ALL of the new stall handling

 

I think #67 will definitely work, #66 will probably work, and I'm giving it 10% odds that #65 will work.

 

This "stall handling" code that's causing all of the trouble was *supposed* to make things more robust by doing better error recovery when something went wrong on the "control endpoint", which is the main sub-channel on the USB connection that Windows uses to set up and maintain the connection.  There are various error conditions that can cause a USB "stall", which is basically an error recovery signal that makes both side of the connection reset their internal state so that everyone is back in sync after an error.  The code I added was meant to accomplish that re-sync more reliably, but obviously it was just making things worse.  The original mbed version of the USB library has very little handling for stall conditions at all, but the hardware documentation seems to suggest that the software has to take certain steps to recover, so this new code was my attempt to do what the hardware manual says you're supposed to do.  The original mbed library might have had it right by just doing nothing - it's possible that the hardware is handling everything internally and the software should just stay out of its way.  But that's not what I get from reading the manual and looking at the Freescale reference software.

 

So anyway, #65 is an attempt to keep the extra error recovery code after fixing a possible problem in its logic that I spotted on closer inspection.  Now that we know this is the source of the problem, I'm looking at it very closely.   I'm hoping that this version will be the best of both worlds - that we can keep the new error recovery code and *not* break everything on your machines.  But in case the error recovery is still wrong, I took it out in #66 for the special control endpoint - so just for that endpoint it goes back to the low-effort mbed version.  And then for #67 I took out all of the error recovery code for all endpoints.

 

Thanks again for all of the careful testing and feedback.  I know how time-consuming that is.  Hopefully this will be the last round of testing needed and I can do a proper release that'll work for everyone.  If the outcome is that #65 works for you, then I think we'll have a good, solid solution that I can incorporate into the main USB library.  If #65 doesn't work but 66 and/or 67 are good, then I'll probably just ditch the error recovery code for now and hope it's truly not needed.

[shadowshd]

Hi Mike,

 

Thanks for all these interesting informations, thanks to you we now know better how do things are working

 

You're proving that there's often an entire world between manuals and reality...

And please dont apologize, it's a pleasure to discuss an issue with you and try to resolve it 

 

I'll try #65-#67 tonight, I must leave for work, and as usual will feedback

[Mace]

#65 - #67 All work on my rig under Win7 x64 Mike - they load and reload fine, all button and other functions are stable. Build 33 used to lock up if I left it running unattended, say with the machine in attract mode. So I'm soak testing #65 at present, reboots and so on.

 

Great job Mike, outstanding.

[shadowshd]

Agree with Mace, #65 to #67 are working fine, green/blue LED state every time

 

I can spread the good news on our french forum

 

Very great job Sir

 

Please don't hesitate to ask if you need more testing, I'll glad to be a beta tester for you Mike

 

++

[mjr]

#65 - #67 All work on my rig under Win7 x64 Mike - they load and reload fine, all button and other functions are stable. Build 33 used to lock up if I left it running unattended, say with the machine in attract mode. So I'm soak testing #65 at present, reboots and so on.

Agree with Mace, #65 to #67 are working fine, green/blue LED state every time

 

I can spread the good news on our french forum

 

That's wonderful news!

 

Let me know if you do run into any longer-term problems with it, but since it looks for now like it's finally working properly, I'll incorporate the #65 changes into the main USB library and update the main Pinscape_Controller fork with the new version.

 

Thanks for all your help tracking this down!

[shadowshd]

Yeah very good news thanks to you and your support Mike

That feeling of achieving things together, by these times of troubles, has more value than everything

I don't think we'll get troubles anymore, Pinscape Controller has always been solid rock since I use it - now I just can't wait to add the Expansion Board in my cab

Once again, if you need peoples to beta test future revisions of the firmware, don't hesitate to ask Mike, if I can help a little, it will be with great pleasure

Thank you again and have a nice Valentine's Day !

++

[Mace]

No worries, I'll run #65 and let you know if anything out of the ordinary occurs.

Thanks Mike, just shout if you want anything else tested.

[LeStef31]

Thanks a lot for the support and the time you spent.

Did you keep the reverse CDD fix in the last build ?

 

Thanks

Stéphane

 

BTW, sorry to have put the mess with my reverted CDD ;-)

Edited by LeStef31, 14 February 2016 - 02:25 PM.

[Joppnl]

The new version looks good in connecting! Good Job!

 

Question: for those who installed the KLZ also as nudging device :

 

i'm having problems with the KLZ working together with the mechanical action/firing of the solenoids.

 

When the sensitivity in VP is good for nudging the ball will flow around when the popbumpers or other solenoids are being fired and when I lower down the sensitivity nudging won't work anymore.....

 

Do you experience this as well and if so, were you able to solve this? (and how??)

 

thank you!

Edited by Joppnl, 14 February 2016 - 08:49 PM.

[mjr]

I've updated the main project repository with the working USB library, so you should be able to update to the latest published version on the main branch now (http://mbed.org/user...ape_Controller/).  The _v1 branch is also updated to the final working version with some cosmetic changes merged from the main branch, so both branches should now be in sync.

 

I'll keep the _v1 branch around to allow reverting to the stable version more easily as I continue working on updates to the main version.

 

 

Thanks a lot for the support and the time you spent.

Did you keep the reverse CDD fix in the last build ?

 

Yes - that change should be in the latest versions on both branches (the main branch and the _v1 fork).

 

 

The new version looks good in connecting! Good Job!

 

Really glad to hear that!  I think this means that the new version is working for everyone who reported USB problems.  If I've forgotten any reports or anyone else is still having problems with the USB connection, let me know.

 

 

 

Question: for those who installed the KLZ also as nudging device :

 

i'm having problems with the KLZ working together with the mechanical action/firing of the solenoids.

 

When the sensitivity in VP is good for nudging the ball will flow around when the popbumpers or other solenoids are being fired and when I lower down the sensitivity nudging won't work anymore.....

 

Do you experience this as well and if so, were you able to solve this? (and how??)

 

I haven't ever had problem with that, so it's definitely not the "normal" behavior.  Whatever's causing it should be fixable.  It's hard to know what the problem is without being able to come over and look at your machine (which is impractical given that we're on different continents!).  But I can give you a couple of ideas for things to look at.

 

1.  The most obvious possibility is that your "gain" settings in VP are too high, making VP hypersensitive.  So the first thing to try is to turn down the VP gain settings. As you say, that'll also reduce the effect from intentional nudges, but hopefully you can find a happy medium.

 

I've found from talking to people on the forums that different people have different expectations for what "realistic" nudging looks like.  It's possible that your preference is for much more sensitive nudging than I like, so that could explain why you haven't been able to find that happy medium so far.  When you're testing your settings, do you feel like the nudges you're applying are comparable in force to the cabinet vibration from the solenoids?  If so, that might be the problem - if you want your manual nudges to register when they're the same size as solenoid vibration, then the solenoid vibration is necessarily going to register too.

 

If you haven't played with a real machine in a while, it might be worth finding one somewhere and playing around with it a bit to calibrate your sense of the real physics.  I've found that VP and other video pinball games really mess with that because they tend to exaggerate, and not just a little.  E.g., if you fire up one of the Farsight tables on an iPad and tap the nudge control, the ball jumps halfway up the playfield.  In contrast, if you load the ball onto the plunger on a real machine and start nudging the cabinet, it's amazing how hard you have to shove it before the ball even budges.

 

So it's actually more realistic to go for a less-is-more approach to the virtual nudging.  But I don't want to suggest that you have to settle for dead and unresponsive to get decent stability.  There should be a range where it's responsive, even a bit exaggerated if you want, but not so hyper-sensitive as you've been seeing.

 

2.  The second most likely thing is that your KL25Z isn't nailed down securely enough inside the cabinet.  Assuming you have a roughly standard cabinet, and it's on good sturdy legs, the sheer inertia of the cabinet should be enough to damp out a lot of the background vibration and jolts from the solenoids.  You should make sure that your KL25Z is attached really firmly so that it can't vibrate or wobble around inside the cab.  It shouldn't move at all if you wiggle the USB wires, for example.

 

3.  It's possible, though unlikely, that you're having some kind of electrical interference.  I doubt this is it, since the KL25Z overall seems really well isolated and pretty much immune to power spikes.  But hopefully all of your solenoids and motors are protected by flyback diodes.

[shadowshd]

Thanks Mike

 

By the way, I dunno if I missed the information (sorry if I did), but has the Config Tool been updated to "remove" the settings not correctly saved in the KL, you know the bug that makes the KL blinks yellow/green instead of blue/green, which workaround is to uncheck/check/uncheck/check Enable Sensor ?

 

Thanks again and have a nice day

 

++

[mjr]

By the way, I dunno if I missed the information (sorry if I did), but has the Config Tool been updated to "remove" the settings not correctly saved in the KL, you know the bug that makes the KL blinks yellow/green instead of blue/green, which workaround is to uncheck/check/uncheck/check Enable Sensor ?

 

That bug was actually in the controller software - the config tool was innocent.  The latest version does indeed include that fix.  (The fix was in revision #34, so all of the subsequent versions include it.)

[shadowshd]

Thanks Mike 

 

++

[LeStef31]

Hi Mike,

after having installed the last software version I've got the red light issue each time I restart the computer.

The KLZ is plugged on an USB2 port on the mother board.

 

I've reinstalled the previous version and I don't have the red light issue at startup. (maybe only a few time but not always..)

 

Do you think that something in the new version may affect the startup ?

 

Thanks

 

Stéphane

[mjr]

after having installed the last software version I've got the red light issue each time I restart the computer.

The KLZ is plugged on an USB2 port on the mother board.

 

I've reinstalled the previous version and I don't have the red light issue at startup. (maybe only a few time but not always..)

 

Do you think that something in the new version may affect the startup ?

 

If it happens in one version and not the other, you're probably right that a change between the versions is responsible.

 

Can you tell me specifically which versions are the "new" and "old" ones you're talking about?  There have been so many lately I want to be sure I'm looking at the same thing.

 

Also, is it only on reboot that this happens?  For example, if you plug it in with the computer already running, it's okay?  Or, if the computer is turned off entirely and you turn it on with the device plugged in, it's also okay?  Again, just want to be sure I'm looking at the right symptoms.

[sasa12345]

I have the latest version of interruptions, and on the other pc never stopped ..

Is it possible to perform restart button on one of the pins?

[LeStef31]

 

after having installed the last software version I've got the red light issue each time I restart the computer.

The KLZ is plugged on an USB2 port on the mother board.

 

I've reinstalled the previous version and I don't have the red light issue at startup. (maybe only a few time but not always..)

 

Do you think that something in the new version may affect the startup ?

 

If it happens in one version and not the other, you're probably right that a change between the versions is responsible.

 

Can you tell me specifically which versions are the "new" and "old" ones you're talking about?  There have been so many lately I want to be sure I'm looking at the same thing.

 

Also, is it only on reboot that this happens?  For example, if you plug it in with the computer already running, it's okay?  Or, if the computer is turned off entirely and you turn it on with the device plugged in, it's also okay?  Again, just want to be sure I'm looking at the right symptoms.

 

 

Hi, I dont

 

 

after having installed the last software version I've got the red light issue each time I restart the computer.

The KLZ is plugged on an USB2 port on the mother board.

 

I've reinstalled the previous version and I don't have the red light issue at startup. (maybe only a few time but not always..)

 

Do you think that something in the new version may affect the startup ?

 

If it happens in one version and not the other, you're probably right that a change between the versions is responsible.

 

Can you tell me specifically which versions are the "new" and "old" ones you're talking about?  There have been so many lately I want to be sure I'm looking at the same thing.

 

Also, is it only on reboot that this happens?  For example, if you plug it in with the computer already running, it's okay?  Or, if the computer is turned off entirely and you turn it on with the device plugged in, it's also okay?  Again, just want to be sure I'm looking at the right symptoms.

 

 

The latest version is the one I've built on the repository. The old one is the one I've installed in december 2015 before you start working on the reverse CDD issue.

 

If I plug with the computer already running it starts ok everytime.

If I turn off and turn it on with the device plugged, i have the red light blinking and need to press the reset button (or unplug / replug) to have the green light.

 

Several people fix this issue with the use of an usb hub or USB PCI card. It happens only with the mother board built-in usb port.

 

Thanks

Stéphane

[shadowshd]

I have the same red blinking LED issue if I plug my KL on one of my motherboard's USB port.

 

Stef you're right, the best fix I have found yet is to add a PCI USB board and plug my KL on this board, then my KL is always green/blue every time I (re)boot my cab.

 

This issue exists since the beginning for me, back in last july.

 

++