Jump to content



Photo
* * * * * 3 votes

New DIY plunger design


  • Please log in to reply
734 replies to this topic

#441 vampirolatino2

vampirolatino2

    Pinball Fan

  • Members
  • PipPipPipPip
  • 1,430 posts

  • Flag: Spain

  • Favorite Pinball: Medieval Madness

Posted 03 April 2015 - 04:11 AM

Sorry, forgot that it shows all the line. Mine is the 3rd one: 100 mm Length of Travel, Lever End Style “A"


I choose this line because of the features:

 

Features
■ Long life carbon element
■ Assortment of resistance tapers
■ 45 mm, 60 mm and 100 mm travel lengths
■ Single and dual gang elements
■ Long operational life
■ Tracking error within ±2 dB


#442 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,068 posts

  • Flag: United States of America

  • Favorite Pinball: Theatre of Magic

Posted 23 April 2015 - 05:53 AM

hi mjr did you find the time to take a look at the triple tilting problem for tilt bob ?

 

I think I have a solution.  It's actually pretty simple - it just requires a small .vbs script that you add to your Tables directory, and it should work automatically (as long as you have the default key settings).

 

Here's a link to the script:

 

https://www.dropbox....PlugIn.vbs?dl=0

 

Setup instructions are at the top of the script.

 

This seems to work well with all of the ROM-based tables I've tested.  This basically replaces the tilt key handling in VP's core Visual Basic scripts to remove all of the fake nudge physics effects but keep the real tilt switch signal to the ROM.  This lets the ROM do its normal warning and/or tilt, so most tables should work just like the real thing.

 

It's possible for tables to override the core script key handling.  If you run into any tables that still have the fake nudge after installing this script, that's probably what's going on.  Search the table's script for key handlers for keyBangBack or key code 20 (they're the same thing - that's the internal code for the "T" key).  You should be able to just remove any such handlers entirely for ROM-based tables so that the core handlers are used instead.  Older EM tables that don't have ROMs will probably also need to be hand-customized, since those don't tend to use the core scripts at all.  There are more details and instructions in the script comments.

 

Hopefully this will solve the problem for you!


Edited by mjr, 23 April 2015 - 05:57 AM.


#443 Gribnif

Gribnif

    Hobbyist

  • Members
  • PipPip
  • 10 posts

  • Flag: ---------

  • Favorite Pinball: Twilight Zone

Posted 30 April 2015 - 04:27 PM

I splurged and bought the CCD for plunger simulation, and am having trouble getting it to work correctly. When I use the tool to view the CCD output, it shows what I believe is a good range of black and white pixels, and they change properly when I pull back the plunger. The min is around 4000 and the max is around 30000 with zero and saturated values both 0.

The problem is that both the Windows Joystick diagnostic and VP itself show the position as rapidly flickering between the correct state and fully covered (as though the plunger isn't pulled back at all.) Any suggestions about what the problem could be?

#444 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,068 posts

  • Flag: United States of America

  • Favorite Pinball: Theatre of Magic

Posted 01 May 2015 - 04:35 AM

I splurged and bought the CCD for plunger simulation, and am having trouble getting it to work correctly. When I use the tool to view the CCD output, it shows what I believe is a good range of black and white pixels, and they change properly when I pull back the plunger. The min is around 4000 and the max is around 30000 with zero and saturated values both 0.

The problem is that both the Windows Joystick diagnostic and VP itself show the position as rapidly flickering between the correct state and fully covered (as though the plunger isn't pulled back at all.) Any suggestions about what the problem could be?

 

I can think of a couple of possibilities.  

 

- An obvious one that you've probably already checked is that it could be an intermittent problem with one of the wires - maybe one of the solder joints isn't quite solid, or you have a connector that isn't making perfect contact.  

 

- Could you be moving the plunger past the limit of the CCD window, so that the shadow isn't falling anywhere on the window, or too close to one end?  If this only happens when you pull the plunger all the way back (or it's at rest all the way forward), and it's stable when it's more toward the middle of the range, that might be the problem.  If that's it, you just need to realign the CCD so that the shadow is still a bit inside the window when the plunger is all the way back and all the way forward.

 

- Outside possibility, but do you have any bright blinking lights inside the cab?  Maybe you have an indicator LED that's washing out the sensor image intermittently.

 

- You could also try running the calibration.  I don't think calibration would make the difference for this particular symptom, but it could be worth a try just to be sure.


Edited by mjr, 01 May 2015 - 04:36 AM.


#445 Spektre

Spektre

    Enthusiast

  • Members
  • PipPipPip
  • 91 posts

  • Flag: ---------

  • Favorite Pinball: South Park

Posted 07 May 2015 - 05:03 AM

Hi Mike,

 

Could you point be to the download of the version of the firmware  that reads an analog potentiometer?

 

Thanks!



#446 Spektre

Spektre

    Enthusiast

  • Members
  • PipPipPip
  • 91 posts

  • Flag: ---------

  • Favorite Pinball: South Park

Posted 07 May 2015 - 05:13 AM

in the hardware installguide on mbed is stated that board FRDM-KL25Z is best mount in front on bottem , i have in my cabinet shaker in front , can i better not install it under my lockbar then , if i mount it on bottem in front will the nudge not be affected by the shaker ??

 
Mounting it under the lockbar should be okay, but I don't think it'll make much difference one way or the other with respect to the shaker.  Cabinets are pretty rigid, so I expect the vibration from the shaker will be transmitted to the top of the lockbar without much damping.  For what it's worth, my shaker is mounted a little forward of center on the left side, and the KL25Z is mounted a little forward of that toward the middle, and I don't see much obvious effect on the ball from the shaker.  The shaker is rather high frequency compared to nudging; I think it largely cancels itself out on the time scale that's important to ball motion.  But if you want to mount it near the lockbar anyway, I don't think that'll do any harm.  The important things are that it's roughly horizontal and fairly near the front of the machine.  Vertical position shouldn't make much difference.


Has anyone found that horizontal POSITION matters much? Obviously it should be coplanar to the horizontal axis, but I have no room in the center front of my cabinet. Would mounting it offset to the left side matter?

#447 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,068 posts

  • Flag: United States of America

  • Favorite Pinball: Theatre of Magic

Posted 07 May 2015 - 05:18 AM

Hi Mike,

 

Could you point be to the download of the version of the firmware  that reads an analog potentiometer?

 

Thanks!

 

It's all one big happy version now.  You'll need to make a private copy of the repository on mbed and edit the file config.h - you just need to comment out the line that enables the CCD and un-comment the line that enables the potentiometer.  It should be self-explanatory from the comments, but if you have any trouble finding it, let me know.



#448 Spektre

Spektre

    Enthusiast

  • Members
  • PipPipPip
  • 91 posts

  • Flag: ---------

  • Favorite Pinball: South Park

Posted 07 May 2015 - 05:19 AM

Has anyone released a fork for this code using an analog input and an A/D? Lemming had said he worked on it.

 
I have uploaded a fork.
 
PS - Perhaps Mike could add official support for analog linear pots and other similar devices that report a simple analog 0~1023 range with calibration functionality in the Windows configuration utility etc. He's a much better coder than I.

 
Thanks for publishing your updates!
 
I'll definitely look at integrating that into the main branch at some point.  I agree that it would be worthwhile to make it work with the calibration scheme to get the rest position calibrated correctly.  That shouldn't be hard conceptually; it'll just take a little rearranging of the code.


Mike. Have you been able to fold these changes into the main branch?

edit: Nevermind. I see that have been folded in.

Edited by Spektre, 07 May 2015 - 05:39 AM.


#449 Spektre

Spektre

    Enthusiast

  • Members
  • PipPipPip
  • 91 posts

  • Flag: ---------

  • Favorite Pinball: South Park

Posted 07 May 2015 - 05:32 AM

Sorry, please disregard the request for the build guide. Google continues to bring up the August 2014 version, but I did located the Feb. 2015 build guide and see the section explaining the potentiometer added.

#450 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,068 posts

  • Flag: United States of America

  • Favorite Pinball: Theatre of Magic

Posted 07 May 2015 - 05:37 AM

Has anyone found that horizontal POSITION matters much? Obviously it should be coplanar to the horizontal axis, but I have no room in the center front of my cabinet. Would mounting it offset to the left side matter?

 

Mine is mounted pretty close to center, so I haven't tried that, but my intuition is that it shouldn't make much difference.  The cabinet is so much longer than it is wide that I think having it close to the front is important to pick up the side-to-side motion (since you're applying forces from the front end), but front-to-back motion should be pretty uniform across the width.



#451 Gribnif

Gribnif

    Hobbyist

  • Members
  • PipPip
  • 10 posts

  • Flag: ---------

  • Favorite Pinball: Twilight Zone

Posted 09 May 2015 - 01:34 AM

 

I splurged and bought the CCD for plunger simulation, and am having trouble getting it to work correctly. When I use the tool to view the CCD output, it shows what I believe is a good range of black and white pixels, and they change properly when I pull back the plunger. The min is around 4000 and the max is around 30000 with zero and saturated values both 0.

The problem is that both the Windows Joystick diagnostic and VP itself show the position as rapidly flickering between the correct state and fully covered (as though the plunger isn't pulled back at all.) Any suggestions about what the problem could be?

 

I can think of a couple of possibilities.  

 

- An obvious one that you've probably already checked is that it could be an intermittent problem with one of the wires - maybe one of the solder joints isn't quite solid, or you have a connector that isn't making perfect contact.  

 

- Could you be moving the plunger past the limit of the CCD window, so that the shadow isn't falling anywhere on the window, or too close to one end?  If this only happens when you pull the plunger all the way back (or it's at rest all the way forward), and it's stable when it's more toward the middle of the range, that might be the problem.  If that's it, you just need to realign the CCD so that the shadow is still a bit inside the window when the plunger is all the way back and all the way forward.

 

- Outside possibility, but do you have any bright blinking lights inside the cab?  Maybe you have an indicator LED that's washing out the sensor image intermittently.

 

- You could also try running the calibration.  I don't think calibration would make the difference for this particular symptom, but it could be worth a try just to be sure.

 

Thanks for the suggestions. I did try them all.

 

I finally resorted to tinkering with the firmware source code. It turns out that something in the logic used by the "firing" variable is causing the problem. I short-circuited the "if" statements at lines 1448 and 1509 of main.cpp by changing them to "if (0)", and that completely fixed the problem for me.

 

Not only that, but effectively removing the "firing" code in this way doesn't even seem to have any negative effect on game play, so far. I think the plunger might move the ball a little too much based on how far I'm pulling it back, but that could probably be adjusted in VP.

 

Let me know if you want me to try a different version of the code or anything, to debug what's there. Personally, I think you could just remove the firing logic, or make it optional.



#452 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,068 posts

  • Flag: United States of America

  • Favorite Pinball: Theatre of Magic

Posted 13 May 2015 - 01:50 AM

 

I finally resorted to tinkering with the firmware source code. It turns out that something in the logic used by the "firing" variable is causing the problem. I short-circuited the "if" statements at lines 1448 and 1509 of main.cpp by changing them to "if (0)", and that completely fixed the problem for me.

 

Not only that, but effectively removing the "firing" code in this way doesn't even seem to have any negative effect on game play, so far. I think the plunger might move the ball a little too much based on how far I'm pulling it back, but that could probably be adjusted in VP.

 

Let me know if you want me to try a different version of the code or anything, to debug what's there. Personally, I think you could just remove the firing logic, or make it optional.

 

The firing code should definitely be included.  It improves the behavior during release motions where the plunger is moving too fast for the sensor to read.  The effect isn't always obvious - it affects the consistency of release strength, so if you disable that code the difference you'll see is that the release strength won't be as repeatable for a given pull distance.

 

I'm assuming you're using the latest.  Did you change any options from the defaults in config.h, or are you using everything at defaults?  If you've changed any options, there might be an interaction with an option setting that I haven't tested.



#453 boiydiego

boiydiego

    Pinball Fan

  • Members
  • PipPipPipPip
  • 978 posts
  • Location:baal

  • Flag: Belgium

  • Favorite Pinball: flinstones,t2 chrome edition,wcs,afm,fish tales,medieval,rollercoaster tycoon,taxi

Posted 14 May 2015 - 08:49 AM

 

hi mjr did you find the time to take a look at the triple tilting problem for tilt bob ?

 

I think I have a solution.  It's actually pretty simple - it just requires a small .vbs script that you add to your Tables directory, and it should work automatically (as long as you have the default key settings).

 

Here's a link to the script:

 

https://www.dropbox....PlugIn.vbs?dl=0

 

Setup instructions are at the top of the script.

 

This seems to work well with all of the ROM-based tables I've tested.  This basically replaces the tilt key handling in VP's core Visual Basic scripts to remove all of the fake nudge physics effects but keep the real tilt switch signal to the ROM.  This lets the ROM do its normal warning and/or tilt, so most tables should work just like the real thing.

 

It's possible for tables to override the core script key handling.  If you run into any tables that still have the fake nudge after installing this script, that's probably what's going on.  Search the table's script for key handlers for keyBangBack or key code 20 (they're the same thing - that's the internal code for the "T" key).  You should be able to just remove any such handlers entirely for ROM-based tables so that the core handlers are used instead.  Older EM tables that don't have ROMs will probably also need to be hand-customized, since those don't tend to use the core scripts at all.  There are more details and instructions in the script comments.

 

Hopefully this will solve the problem for you!

 

this would be best thing of 2015 for me if it works gone test it right away will report back to you MJR ..


boiydiego___gebruik-n2kbkyc.png


#454 boiydiego

boiydiego

    Pinball Fan

  • Members
  • PipPipPipPip
  • 978 posts
  • Location:baal

  • Flag: Belgium

  • Favorite Pinball: flinstones,t2 chrome edition,wcs,afm,fish tales,medieval,rollercoaster tycoon,taxi

Posted 14 May 2015 - 09:12 AM

MJR YOU ARE THE GREATEST THE PROBLEM WAS BUGGING ME FROM WHEN I FIRST STARTED OUT WITH VP YOU FIX IT INCREDIBLE WORK ,ADMINS PROMOTE HIM FOR HIS DEDICATION FOR VP  ....


VP devs please implement this in vp 10 ...


Edited by boiydiego, 14 May 2015 - 09:12 AM.

boiydiego___gebruik-n2kbkyc.png


#455 Spektre

Spektre

    Enthusiast

  • Members
  • PipPipPip
  • 91 posts

  • Flag: ---------

  • Favorite Pinball: South Park

Posted 16 May 2015 - 06:55 PM

Hey MJR, One more quick question before wiring this up.
 
I am planning on using the "potentiometer" input pin, but I am not using a pot.   I've scaled my LVDT to output a voltage between 0-3.3V however I wanted to make sure there will be no timing problem that ends up frying a board.  (Like the voltage being present before the pins are configured as input or some such)
 
I could only see this as an issue if P3V3 is switched, which it doesn't appear to be.
 
Also, is there a method to disable LEDWiz emulation in the firmware or software config such that it does not present to the system as a second LEDWiz controller?
 
Also disabling the ZB LaunchBall feature as so:

// To disable this feature, just set ZBLaunchBallPort to 0 here.

const int ZBLaunchBallPort = 0;


Causes the following:

Warning: Subscript out of range in "main.cpp", Line: 1620, Col: 33
Warning: Subscript out of range in "main.cpp", Line: 1664, Col: 31

Edited by Spektre, 16 May 2015 - 11:46 PM.


#456 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,068 posts

  • Flag: United States of America

  • Favorite Pinball: Theatre of Magic

Posted 16 May 2015 - 10:59 PM

Hey MJR, One more quick question before wiring this up.

 

I am planning on using the "potentiometer" input pin, but I am not using a pot.   I've scaled my LVDT to output a voltage between 0-3.3V however I wanted to make sure there will be no timing problem that ends up frying a board.  (Like the voltage being present before the pins are configured as input or some such)

 

I could only see this as an issue if P3V3 is switched, which it doesn't appear to be.

 

Your guess is as good as mine on that.  I kind of doubt you could damage the KL25Z board with a 3.3V input regardless of how the pins are configured; I haven't seen anything in the documentation warning about that sort of thing.

 

 

Also, is there a method to disable LEDWiz emulation in the firmware or software config such that it does not present to the system as a second LEDWiz controller?

 

No, it always looks like an LedWiz because it uses that as the USB ID.  If you really want to change it, you could redefine USB_VENDOR_ID in main.cpp, although then you'd have to change the Windows config program to look for that other ID.  Do you have a specific concern about having it appear as an LedWiz?  I can't think of any conflict with DOF or VP or anything else from having a device present but not used.


Edited by mjr, 16 May 2015 - 10:59 PM.


#457 Spektre

Spektre

    Enthusiast

  • Members
  • PipPipPip
  • 91 posts

  • Flag: ---------

  • Favorite Pinball: South Park

Posted 17 May 2015 - 08:15 PM

Interesting result today.

 

I connected up my LVDT plunger and everything worked...almost.

 

The accelerometer seems to have a small amount of noise on its output, but the plunger has a significant amount.  When looking at it in gamepad setup in Windows the Z axis bounces around a good bit.

 

I got out the scope to measure and found my LVDT output is noise free until plugged into the Freescale board.  Then the 0-3.3V A/D input has a varying amount of noise up to 0.5V in amplitude!  Since I am not using a pot the only pin I have connected is the specified A/D pin.  Thus the power and ground for the board are being supplied by the USB connector only.  I'll try wiring up the header GND pins and see if that quiets things down.


Edited by Spektre, 17 May 2015 - 08:15 PM.


#458 Spektre

Spektre

    Enthusiast

  • Members
  • PipPipPip
  • 91 posts

  • Flag: ---------

  • Favorite Pinball: South Park

Posted 18 May 2015 - 09:58 PM

Well good news.  Connecting up the I/O header ground pins got rid of the noise on the A/D input.  Evidently the USB ground is not particularly strong or my USB ground is noisy.



#459 mjr

mjr

    Pinball Wizard

  • Members
  • PipPipPipPipPip
  • 3,068 posts

  • Flag: United States of America

  • Favorite Pinball: Theatre of Magic

Posted 18 May 2015 - 10:37 PM

Well good news.  Connecting up the I/O header ground pins got rid of the noise on the A/D input.  Evidently the USB ground is not particularly strong or my USB ground is noisy.

 

I'm glad to hear that worked - that was going to be my first suggestion.  It seems really important with all of these logic circuits to have solid grounding.  

 

The other suggestion was going to be to add one or more filter caps (between the KL25Z power supply and ground, and between the sensor power supply and ground).  Fortunately it looks like you won't have to do mess with that, but I thought I'd mention as something to try for anyone else having similar problems.  I'm kind of a neophyte with electronic hardware, but the thing I keep finding is that logic circuits really don't cope well with the slightest bit of noise from the power supply.  Filter caps seem to be the one-size-fits-all solution for that, the key being to place them physically as close as possible to the affected circuits.



#460 Spektre

Spektre

    Enthusiast

  • Members
  • PipPipPip
  • 91 posts

  • Flag: ---------

  • Favorite Pinball: South Park

Posted 29 May 2015 - 04:59 AM

Well file this in the nothing ever comes easy file.

 

I could use some brainstorming on this.

 

My cab has been at VP9.9.0.  I have just finished connecting my LVDT based plunger which puts out a 0-3.3V signal to the Freescale board and have been trying it out in 9.9.0.  There is still a small amount of noise on the plunger.  Checking this with the oscilloscope shows the LVDT puts out a steady signal until plugged into the Freescale input.  Once plugged in (even after connecting the Freescale's I/O GND pin to GND, there is still a small amount of noise.

I'll try throwing a cap on between the 3.3V I/O pin and the GND I/O pin.  I am only using the Freescale board to read the plunger and for the accelerometer's nudge.  I am NOT using any LEDWiz function nor joystick button inputs.

 

The noise sometimes completely damps out and even when present is small and just causes a very minor shake on the plunger graphic (or on the plunger status bar in windows calibration.

 

1.  Any other ideas on the source of the noise?  Perhaps the Freescale's A/D is just a tad noisy.

 

2.  I know it will vary cab to cab, but I'd like to hear where the user's X/Y gain for the nudge set to?

 

AND NOW THE BIGGIE

 

3.  Before dialing in the nudge, I wanted to upgrade to VP9.9.1 to get the nudge filtering option.  I downloaded 9.9.1's exe, which came with 2 dll's and updated them.  Now whenever playing a table (ANY of them, even a blank table), as soon as the ball enters the lane it is fired out as though a kicker where there.  The plunger does not animate at all, however the plunger firing sound plays.

 

I tested 5 tables, including a blank, Southpark, Abracadabra (no db2s) and all operated the same way.  As soon as the ball appears in the shooting lane it is fired at what looks to be a maximum plunger hit.  The plunger never pulls back.

 

I switched back to vp9.9.0's exe (left the updates dlls alone) and the problem went away.

 

I hope this is s simple thing.   Any ideas?