734 replies to this topic

[Gilrock]

Yes I'm using the KL25Z board.  Which properties window looks different?  The windows game controller properties or the key settings in VP?  Also mjr recommended 1000% instead of 150%.

 

I'm using the 8/20 build of VP mjr provided in his dropbox.  Building the MBED project is another problem I ran into so I'm using the BIN file from his dropbox.  I tried to follow the instructions.  I signed up for the MBED website and goto the Pinscape_Controller project but when I hit "Build repository" it takes me to a page with a combo-box titled "Choose target platform:" but there are no choices available.  And when you leave it blank since there are no choices hitting the "Compile" button causes the error "No licence available for requested compilation target".

[connorsdad]

Yes I'm using the KL25Z board.  Which properties window looks different?  The windows game controller properties or the key settings in VP?  Also mjr recommended 1000% instead of 150%.
 
I'm using the 8/20 build of VP mjr provided in his dropbox.  Building the MBED project is another problem I ran into so I'm using the BIN file from his dropbox.  I tried to follow the instructions.  I signed up for the MBED website and goto the Pinscape_Controller project but when I hit "Build repository" it takes me to a page with a combo-box titled "Choose target platform:" but there are no choices available.  And when you leave it blank since there are no choices hitting the "Compile" button causes the error "No licence available for requested compilation target".

You need to click on the platforms tab at the top of the page, find the kl25z board and add it to your mbed compiler (Option on the right I think). It will now show up as target platform.

[Gilrock]

Ok I just figured out how to rebuild the Pinscape code.  If the steps were written out somewhere I must have missed it due to information overload when doing something new.  Anyways I poked around on the MBED website and when I hit the Compiler button on the top right it took me to a page where you can manage your projects.  I clicked Import and a window popped up saying I didn't have any platforms on my account and that brought me to a page where I was able to select the KL25Z board.  So then I was able to go back to the project page and the Build repository command now works since I have a platform assigned to my account.  I also was able to go back to the Compiler page and Import the project so I can see all the source code and build it from there so I'm in programmer heaven.  And I noticed on the home page there was the link for the Config tool I had asked about earlier.  I hadn't noticed it before and didn't see it in the dropbox so I was wondering what that was when I heard it mentioned.

 

Edit:: Thanks connersdad....I must have been typing this when you replied.  So the unfortunate thing is I gotta work all day so I can't try anything for several hours.

Edited by Gilrock, 28 August 2014 - 01:57 PM.

[gigalula]

Just place an order for one of these kool KL25Z board. Hope to get it before Christmas... LOL 

[parabolic]

Thanks for adding the input code MJR....works really well

[mjr]

Thanks for adding the input code MJR....works really well

 

Great!  Glad it's working so far!

...and that brought me to a page where I was able to select the KL25Z board.  So then I was able to go back to the project page and the Build repository command now works since I have a platform assigned to my account.  I also was able to go back to the Compiler page and Import the project so I can see all the source code and build it from there so I'm in programmer heaven.  And I noticed on the home page there was the link for the Config tool I had asked about earlier.  I hadn't noticed it before and didn't see it in the dropbox so I was wondering what that was when I heard it mentioned.

 

Glad you got the build going.  Sorry for the missing instructions about the target platform setup - I didn't realize when I wrote the first draft of the guide that there was an extra step needed there.  I've added that to the latest guide, so hopefully the next person to try it will have an easier time.

The mbed project page should be the main place to go for everything now.  It's always automatically up to date with the Freescale software since it pulls directly out of the source control system.   I've added a readme in the dropbox folder pointing people to the mbed page so that they're sure to get the latest versions of all the pieces.

[Gilrock]

Hi mjr...so I'm off work today and digging into this.  I built the repository and put the new bin file on the card.  One thing I'm not sure about is how to verify it actually loads the new image correctly.  I had issues when I was updating the bootloader.  It seemed to take several tries before I got it to update.  I was using the SDA_INFO.HTM page to verify my boot version and it took 3 tries before the version number changed.  So I wanted to know how to be sure its updating your application bin file.  After I place your bin file in the board and then pull the USB cord, wait a few seconds, then plug it back in.  Then I disconnect again and power back up into the bootloader the stats page is showing the application version as 0.00....should I be seeing something different there?  Plus I wanted to verify when you put a new bin file on the board you don't need to plug a second USB cable into the board do you because I've just been disconnecting from the programming port and plugging back into the joystick port to do the updates.

 

So I also tried the config tool and I'm getting an error.  I have Visual Studio 2008 so I did some debugging with the config tool application and I narrowed it down to where its doing the initial communication with the card during the FindDevices method.  The report size is coming back as 13 bytes but your expecting 15 bytes.  After the dialog about that error the form still comes up showing the unit as number 8.  If I try to disable the plunger since I don't have it hooked up yet I get another error "Error sending request to device: The supplied user buffer is not valid for the requested operation (Win32 error 1784)".  I can dig into this more but you may be able to tell me whats wrong quicker than I can find it.

 

Update:  Looking at the USBJoystick.cpp for the embedded code it has const int reportLen = 14;

 

Thanks,

Gil

Edited by Gilrock, 29 August 2014 - 03:00 PM.

[mjr]

Hi mjr...so I'm off work today and digging into this.  I built the repository and put the new bin file on the card.  One thing I'm not sure about is how to verify it actually loads the new image correctly.  I had issues when I was updating the bootloader.  It seemed to take several tries before I got it to update.  I was using the SDA_INFO.HTM page to verify my boot version and it took 3 tries before the version number changed.  So I wanted to know how to be sure its updating your application bin file.  After I place your bin file in the board and then pull the USB cord, wait a few seconds, then plug it back in.  Then I disconnect again and power back up into the bootloader the stats page is showing the application version as 0.00....should I be seeing something different there?  Plus I wanted to verify when you put a new bin file on the board you don't need to plug a second USB cable into the board do you because I've just been disconnecting from the programming port and plugging back into the joystick port to do the updates.

 

So I also tried the config tool and I'm getting an error.  I have Visual Studio 2008 so I did some debugging with the config tool application and I narrowed it down to where its doing the initial communication with the card during the FindDevices method.  The report size is coming back as 13 bytes but your expecting 15 bytes.  After the dialog about that error the form still comes up showing the unit as number 8.  If I try to disable the plunger since I don't have it hooked up yet I get another error "Error sending request to device: The supplied user buffer is not valid for the requested operation (Win32 error 1784)".  I can dig into this more but you may be able to tell me whats wrong quicker than I can find it.

 

Update:  Looking at the USBJoystick.cpp for the embedded code it has const int reportLen = 14;

 

The buffer size error definitely means a version mismatch between the config tool and the controller software - the report size of 13 means that you have an older version of the controller software, so this confirms your suspicions that the KL25Z isn't updating properly.

 

(The controller side and the Windows side will always be off by one on buffer length, by the way.  The "report type" prefix byte is hidden on the device side but visible on the Windows side, so the Windows report length will always be one byte longer.  14 bytes on the controller == 15 bytes on Windows.)

 

First, you should double-check that you installed the right boot loader originally.  There are two versions of the KL25Z boot loader in the PEMicro zip file.  The one you want is MSD-DEBUG-FRDM-KL25Z_Pemicro_v114.SDA.  I think the other one is for use with the Code Warrior dev platform.  This is another detail I added to the guide after other people ran into it, so it might not have been mentioned in the version you first got.

 

There's definitely not much feedback from the boot loader either when you install it or when you load new software with it.  The easiest way I've found to be sure that an update goes through is to keep both USB cables plugged in while you're doing the update.  If you do that, you should hear the Windows "USB device removed" sound effect followed a few second later by the Windows "USB device connected" sound effect.  The boot loader automatically reboots the KL25Z after the install completes, so Windows will detect the device being unplugged and plugged back in.  If that *doesn't* happen, you know something went wrong with the update.  There's also the KL25Z SDA LED - the green LED closer to the programming port, not the RGB LED that the controller software uses as an indicator.  The green LED should blink rapidly while the boot loader is doing a download of new software, and should then turn solid green again after the software is installed.  If it's not solid green at the end of the download, there's something wrong.  

 

One thing to check is that the virtual flash drive on the KL25Z isn't full.  Your web browser is probably putting a suffix - [1].bin, [2].bin, etc - at the end of the filename each time you build a new copy on mbed, so they look like separate files to the KL25Z.  The disk is only 128K so you'll eventually fill it up this way.   I think it automatically clears out old files each time you power cycle the board, so if you're switching cables this might not be an issue for you.  But you might want to look at the drive contents in Windows, and if there are a bunch of old .bin files sitting there, just delete them from Windows to free up space.

 

Apart from the disk-full situation, I can't think of any other failure modes I've run into with the MSD-DEBUG boot loader.  It was a colossal pain to get the boot loader going in the first place because of the Windows 8.1 glitches in the factory firmware, but once I got past those it's been trouble-free, so I'm afraid I don't have anything from own experience that would explain flaky update behavior.

 

Edit: forgot to answer your question about the USB cables.  You are correct - you only need one cable.  You can switch back and forth between the ports as needed.  You *also* can leave both plugged in all the time if you want, but that's not necessary.

Edited by mjr, 29 August 2014 - 06:09 PM.

[Gilrock]

Ok great...thanks for the tips.  I looked into it again and I think I did have the right bootloader.  The mistake I made today when trying to update the application is I put the board into bootloader mode and dragged the bin file over to there instead of booting to flash drive mode.  I've now got it updated and the config tool is working.  The instructions in the PEMicro files can be confusing because they have instructions in the PDF file and different instructions in the BOOTUPDATEAPP_release_notes.txt file. 

 

I don't think the MSD-DEBUG-FRDM-KL25Z_Pemicro_v114.SDA file is the bootloader.  I believe that is the application file that allows the board to boot up as a flash drive.  I believe the file BOOTUPDATEAPP_Pemicro_v111.SDA is the bootloader that people need to get installed first, then the flash driver application, and then put the pinscape bin file onto the flash drive directory.

 

When you install the bootloader and the flash driver application you can click on the SDA_INFO.HTM file and should get a webpage showing results like this...you can see the bootloader version is 1.11 and the application version is 1.14:

Board Name is: FRDM-KL25Z
MicroBoot Kernel Version is: 1.05
Bootloader Version is: 1.11
Installed Application: PEMicro FRDM-KL25Z Mass Storage/Debug App
Application Version is: 1.14
DUID is: 9A933938-8F0881C3-3784D80F-B76DE678
EUID is: A411A239-20628749-1883FA14-957668D6
TUID is: 74823938-473281C2-377D9809-B85CE678
TOA is: 86B6E505-D29AC9CF-41E6B687-EE33F678
TOA2 is: 86B6E505-FBAA6FE4-CDE430D7-3D53E0CC
SUID is: 86B6E505-6C47A61D-37239804-8003EC65

[mjr]

Gilrock, that all sounds exactly right.  The PEMicro instructions are indeed rather confusing, and when I got mine set up it was even more confusing because nothing worked as documented on Windows 8, so I had to go through so many iterations that I'm still fuzzy on the exact steps I carried out.  It sounds like the boiled-down procedure is to first install BOOUPDATEAPP_Pemicro_v111.SDA, and then install MSD-DEBUG-FRDM-KL25Z_Pemicro_v114.SDA - does that sound right?  I'll update the build guide with those specific steps if so, so the next person who attempts this won't have to do so much trial and error.  I'll also add a note that you don't have to go into boot loader mode to load the .bin file, since that's a perfectly reasonable assumption to make based on the steps to that point.

[Gilrock]

Gilrock, that all sounds exactly right.  The PEMicro instructions are indeed rather confusing, and when I got mine set up it was even more confusing because nothing worked as documented on Windows 8, so I had to go through so many iterations that I'm still fuzzy on the exact steps I carried out.  It sounds like the boiled-down procedure is to first install BOOUPDATEAPP_Pemicro_v111.SDA, and then install MSD-DEBUG-FRDM-KL25Z_Pemicro_v114.SDA - does that sound right?  I'll update the build guide with those specific steps if so, so the next person who attempts this won't have to do so much trial and error.  I'll also add a note that you don't have to go into boot loader mode to load the .bin file, since that's a perfectly reasonable assumption to make based on the steps to that point.

Yep that all sounds good.  I think your instructions did tell me to put the file in the flash drive area because I did it that way the first time.  I just messed up when I went to do it a second time.  I originally thought that installing your application was overwriting the flash driver application so that's why I thought I had to update in the boot loader mode.

 

So in the game controller test screen it seems like the board is responding to X and Y rotational movements whereas the nudging of the table is more of a translation movement.  I think that's why when the table is hit it's not easy to tell the direction it was hit because it kinda jitters around both axes.  It almost seems like you could get a more defined response by mounting the board in a way where there is a single spring suspending the board in the center.  Then a hit on the side of the table would cause the board to sway a little bit in a rotational direction as it deflected the spring and it should be more clear which direction the table was hit.  I might experiment with some type of mount for the board to try this out.  Of course I'd probably need to lower the gain depending on the stiffness of the spring.

[mjr]

Yep that all sounds good.  I think your instructions did tell me to put the file in the flash drive area because I did it that way the first time.  I just messed up when I went to do it a second time.  I originally thought that installing your application was overwriting the flash driver application so that's why I thought I had to update in the boot loader mode.

 

Great, I'll add those notes.

 

 

So in the game controller test screen it seems like the board is responding to X and Y rotational movements whereas the nudging of the table is more of a translation movement.  I think that's why when the table is hit it's not easy to tell the direction it was hit because it kinda jitters around both axes.  It almost seems like you could get a more defined response by mounting the board in a way where there is a single spring suspending the board in the center.  Then a hit on the side of the table would cause the board to sway a little bit in a rotational direction as it deflected the spring and it should be more clear which direction the table was hit.  I might experiment with some type of mount for the board to try this out.  Of course I'd probably need to lower the gain depending on the stiffness of the spring.

 

What do you mean by rotational movements?  Do you mean taking the board off its mounts and tilting it?  That'll definitely give you a response along the tilted axis, since it'll be reading the Earth's gravity along that axis.  1g is a rather strong acceleration, so you're going to see bigger numbers out of the accelerometer from steep tilts than moderate nudges.  If you could accelerate a car at 1g, you'd go 0-60 in 2.7 seconds.  Hopefully you're not shoving your cabinet that hard.

 

I really don't think a spring mounting will give you a realistic result.  You'll get rebounds at an oscillation frequency that's a function of the spring tension, unrelated to what the cabinet's doing.  You probably will see bigger numbers, but I think they'll also look pretty random.  More to the point, thought, if you're after realism, you really want the device to read the same accelerations the cabinet is experiencing.  I still think what you're really after here is gain, and that *should* be totally at your control through the VP settings.  I just can't see any reason you'd want to increase the gain mechanically when you can do it so much more linearly and directly in the software.

[mjr]

Ok here's the video I did.  My son is taking the video so you can hear me telling him what to do.  Just let me know if the amount of movement I'm getting in the test screen seems too small.  I do get the ball to move in the game but I'm hitting the machine fairly hard to do it.  You can hear the backbox shaking when I get the ball to create some seperation.

https://www.youtube....h?v=YYoIvZfWL7o

 

That actually looks pretty reasonable in terms of the response.  The joystick control panel response looks about right.  The response you're seeing in VP looks a *little* subdued compared to what I see, but not greatly.  

 

If you turn the VP gain up to something insanely huge, say 10000%, do you see a proportionally bigger response?

[Gilrock]

Yeah the gain is definitely amplifying the effect now.  I put it up to 8000% and I get big nudges.  For my cabinet I'm kinda liking it at 2000% instead of 1000%.

 

Regarding the rotational comment I think I was interpreting the test screen wrong.  It appeared that the cursor was moving in the direction of the tilt but I forgot to notice whether it re-centered itself if I kept the board tilted.  I don't want to unscrew it again to check.  It made me think it was measuring the angle of the board instead of acceleration.

[mjr]

Yeah the gain is definitely amplifying the effect now.  I put it up to 8000% and I get big nudges.  For my cabinet I'm kinda liking it at 2000% instead of 1000%.

 

Great!

 

 

Regarding the rotational comment I think I was interpreting the test screen wrong.  It appeared that the cursor was moving in the direction of the tilt but I forgot to notice whether it re-centered itself if I kept the board tilted.  I don't want to unscrew it again to check.  It made me think it was measuring the angle of the board instead of acceleration.

 

Well, both are right!  Angle of the board == acceleration, thanks to Einstein's equivalence principle.  The big application of accelerometers in smart phones is orientation sensing.  If you have a 3-axis accelerometer (which we do on the KL25Z), you can compute the direction of the acceleration vector the device is registering, and that tells you which way is up, assuming the device is at rest (relative to the Earth's gravitational field).  There's an application note on the manufacturer's web site with a bunch of vector arithmetic giving a recipe for interpreting readings to sense orientation.  For pinball cabinet nudge sensing, we actually want to do the complementary task - we want to assume a fixed orientation, subtract out gravity, and measure what's left over to detect cabinet motion.

 

The auto-calibration will indeed zero out the x/y readings if you hold the board steady at a tilt for about 5 seconds.  You have to hold it very still, so this probably won't happen if you're doing it by hand, but if you clamp it down at a steep tilt it'll zero out.  This s just to compensate for the slight tilt that any real cabinet is going to have at rest - they're never going to be perfectly level.  If the cabinet *were* perfectly level, the x and y projections of the gravitiy vector would be exactly zero (in fact, that's the very definition of "perfectly level").  But that's unrealistic in practice, so the auto-zeroing is there to cancel out the constant gravitational acceleration from the slight tilt of the at-rest cabinet.

[blashyrk]

Got my cab up and running today The nudging works perfect, but is was wondering, can you get the table to tilt? Checked the tilt sensitivity box and tried values from 400 to 50 but to no effect.. Do i need a tiltbob for it to work?

Edited by blashyrk, 30 August 2014 - 12:03 PM.

[sliderpoint]

Yes I'm using the KL25Z board.  Which properties window looks different?  The windows game controller properties or the key settings in VP?  Also mjr recommended 1000% instead of 150%.".

Sorry, really late to reply here, but you were correct. I was looking at the wrong exes when I went to check the %'s



-Mike

[mjr]

Got my cab up and running today The nudging works perfect, but is was wondering, can you get the table to tilt? Checked the tilt sensitivity box and tried values from 400 to 50 but to no effect.. Do i need a tiltbob for it to work?

 

Not sure - I use a mechanical tilt bob myself, so I have the sensitivity set to 0 to disable the software tilt. 

 

Looking at the VP code, I'm not quite sure it's capable of effecting a tilt based on accelerometer nudging.  Here's what's going on internally.  The accelerometer readings are fed into VP's simulated plumb bob model, and VP checks on each physics frame to see if the simulated bob has reached the excursion limit - this is what the "sensitivity" preference setting actually controls.  When it has, VP fires a "Center Tilt" key event to the table script.  This is the same as hitting the Space bar on the keyboard.

 

So, basically, when accelerometer nudging causes a virtual tilt, VP sends a *keyboard* nudge event to the script.  You can probably see the effect on the ball on screen, although it would be tricky to spot - when the tilt occurs, you should see a fake software nudge effect superimposed on top of the accelerometer nudging.  It might be easiest to spot if you nudge back and forth sideways hard enough to trigger a virtual tilt, since the fake nudge will always be a center nudge (i..e, a hard push of the cabinet forward).

 

I think it would be possible to trigger a ROM tilt with enough accelerometer nudging, but it would be really hard.  This scheme imposes a second layer of delay timing.  Each time you get the virtual tilt bob to register a tilt, it will just send a fake nudge to the script.  But the ROM won't get a tilt switch trigger until the *fake* nudging tilts.  To tilt with fake nudging, you have to send a series of fake nudge keys fast enough to get the script to declare a tilt.  And with modern tables, one tilt switch trigger will just get a "tilt warning" from the ROM - you usually need 3 rapid tilt switch signals to trigger an actual ROM tilt.  So I guess there are really three layers of delay filters.

 

This could be fixed in the software, but it would take some significant extension work, because I don't think the ROM-level tilt switch is something VP knows about.  To handle this properly, I think VP would have to introduce a new event for "plumb bob tilt".  What's more, every table script would have to be modified to listen for this event and signal the appropriate switch event to VPinMAME.  I think the current VP code is the way it is because the developers wanted to work within the existing framework and not introduce new events for this.

 

Bottom line: it looks like the best solution is to install a mechanical tilt and wire it to the VPinMAME "T" key.

Edited by mjr, 30 August 2014 - 09:26 PM.

[blashyrk]

Thanks for the answer

[gigalula]

 

Got my cab up and running today The nudging works perfect, but is was wondering, can you get the table to tilt? Checked the tilt sensitivity box and tried values from 400 to 50 but to no effect.. Do i need a tiltbob for it to work?

 

Not sure - I use a mechanical tilt bob myself, so I have the sensitivity set to 0 to disable the software tilt. 

 

Looking at the VP code, I'm not quite sure it's capable of effecting a tilt based on accelerometer nudging.  Here's what's going on internally.  The accelerometer readings are fed into VP's simulated plumb bob model, and VP checks on each physics frame to see if the simulated bob has reached the excursion limit - this is what the "sensitivity" preference setting actually controls.  When it has, VP fires a "Center Tilt" key event to the table script.  This is the same as hitting the Space bar on the keyboard.

 

So, basically, when accelerometer nudging causes a virtual tilt, VP sends a *keyboard* nudge event to the script.  You can probably see the effect on the ball on screen, although it would be tricky to spot - when the tilt occurs, you should see a fake software nudge effect superimposed on top of the accelerometer nudging.  It might be easiest to spot if you nudge back and forth sideways hard enough to trigger a virtual tilt, since the fake nudge will always be a center nudge (i..e, a hard push of the cabinet forward).

 

I think it would be possible to trigger a ROM tilt with enough accelerometer nudging, but it would be really hard.  This scheme imposes a second layer of delay timing.  Each time you get the virtual tilt bob to register a tilt, it will just send a fake nudge to the script.  But the ROM won't get a tilt switch trigger until the *fake* nudging tilts.  To tilt with fake nudging, you have to send a series of fake nudge keys fast enough to get the script to declare a tilt.  And with modern tables, one tilt switch trigger will just get a "tilt warning" from the ROM - you usually need 3 rapid tilt switch signals to trigger an actual ROM tilt.  So I guess there are really three layers of delay filters.

 

This could be fixed in the software, but it would take some significant extension work, because I don't think the ROM-level tilt switch is something VP knows about.  To handle this properly, I think VP would have to introduce a new event for "plumb bob tilt".  What's more, every table script would have to be modified to listen for this event and signal the appropriate switch event to VPinMAME.  I think the current VP code is the way it is because the developers wanted to work within the existing framework and not introduce new events for this.

 

Bottom line: it looks like the best solution is to install a mechanical tilt and wire it to the VPinMAME "T" key.

 

Thanks MJR You just answered one of my question concerning nudging and tilt. I wasn't sure but yep it looks like using mechanical tilt bob and T key is probably the best solution so far.... Thanks again! 

Edited by gigalula, 31 August 2014 - 03:56 PM.