975 replies to this topic

[Joppnl]

Hi Xav,

 

The cable I bought was at the local electronics shop. 4 wires internally with each wire had a number of copper wires around them for shielding.

 

When making the cable I took all these small copper wires of the 4  internal wires and soldered them together to the metal of the housing of the USB connector.

 

The USB connectors I bought on ebay but as long as they can be soldered you're fine.: https://tinyurl.com/connectorUSB  

 

Some pic's below to show you the making of the cable:

 

USB connectors (come by ten but don't cost much:

 

Inside....wire was slightly thicker then the USB connector could handle, therefore I used shrink tube (is that the word? : it shrinks when applying heat) Make sure you don't cross the cable but pin#1 = connected to #1 at the other side #2 to #2, 3 to 3 and 4 to 4.

 

 

Testing the cable: because the leads of the multimeter are to big I must use a needle to get into it.

 

Edited by Joppnl, 07 June 2017 - 08:19 AM.

[xav1971]

Hi Joppnl,

thank you very much for your answer.

I am going to try this solution, build my own shielded USB cable.

I hope it will fix my problem. I cross my finger 

Thanks again Mike and Joppnl

[Slydog43]

Just hooked a few board up to a board.  How can I test this out, sorry for such a newbie question.

 

 

I'm thinking of a test tool to test fire an output.

 

So excited.   I updated the firmware without a hitch

[mjr]

Just hooked a few board up to a board.  How can I test this out, sorry for such a newbie question.

 

 

I'm thinking of a test tool to test fire an output.

 

So excited.   I updated the firmware without a hitch

 

The config tool (see http://mjrnet.org/pi.../swversions.php) has an output tester.  You should make sure you've configured the output ports first using the Settings page.  Then go back to the main page and click Outputs (the light bulb icon).  That'll let you turn outputs on and off.

[tma73]

 

 

Hey mjr,

I have an arcade cabinet with multiple input devices, i.e:

-Aimtrak light gun

-Mayflash Dolphin bar (for wiimote)

-ipac4

-optipac

-.....

 

When I launch Visual Pinball the pinscape controller/analog plunger (used the optical lin. array) doesn't work.

Only way to get it to work is disabling most of the other controllers, which is a pain hehe.

 

The Pinscape controller works fine in Future pinball with other controllers enabled-default.

 

I am running hyperspin and rocketlauncher for my frontends.

Is there a script I could add to rocketlauncher, or VP or even modify a Visual Pinball registry key that would make VP always use the Pinscape Controller?

 

thanks,

Thomas Andrews

[mjr]

I don't know the details of the other devices, so this is only a guess, but I'd suspect the problem is that one of the other input devices is reporting joystick input on the Z axis, which is the plunger input from Pinscape.

 

If you could identify the specific device that's causing the problem, there might be a solution in reconfiguring the other device.  Try turning off the devices one at a time and testing - only turn off ONE at any given time so that you can see if that single device is causing the problem.  For example, turn off the light gun and test.  If it fails, turn the light gun back on and turn off the next device.  The goal is to find one device that's causing the problem.  If you try each device individually and it still fails, try exactly two at a time in each possible combination.  

 

Once you identify the exact device or devices causing the problem, see if you can tell what they're doing with the Z axis on the joystick input.  It might not be for anything you're actually using, so you might be able to turn off that single feature on the conflicting device.  In fact, I think there's a good chance you're not using whatever feature is causing the problem, because if you were, the Pinscape plunger would probably be creating the exact same interference for the other device that the other device is causing for Pinscape.

 

If you identify the source of the problem and it's something that can't be changed on the other device, then the solution will probably have to involve reassigning the Pinscape input to another joystick control axis.  That's not possible right now (well, it's *possible*, if you want to edit the source code, but you can't do it through the config tool), so it would have to be something I'd add to a future version.  So hopefully you can solve it with a little reconfiguration of whichever device is conflicting.

[tma73]

I don't know the details of the other devices, so this is only a guess, but I'd suspect the problem is that one of the other input devices is reporting joystick input on the Z axis, which is the plunger input from Pinscape.

 

If you could identify the specific device that's causing the problem, there might be a solution in reconfiguring the other device.  Try turning off the devices one at a time and testing - only turn off ONE at any given time so that you can see if that single device is causing the problem.  For example, turn off the light gun and test.  If it fails, turn the light gun back on and turn off the next device.  The goal is to find one device that's causing the problem.  If you try each device individually and it still fails, try exactly two at a time in each possible combination.  

 

Once you identify the exact device or devices causing the problem, see if you can tell what they're doing with the Z axis on the joystick input.  It might not be for anything you're actually using, so you might be able to turn off that single feature on the conflicting device.  In fact, I think there's a good chance you're not using whatever feature is causing the problem, because if you were, the Pinscape plunger would probably be creating the exact same interference for the other device that the other device is causing for Pinscape.

 

If you identify the source of the problem and it's something that can't be changed on the other device, then the solution will probably have to involve reassigning the Pinscape input to another joystick control axis.  That's not possible right now (well, it's *possible*, if you want to edit the source code, but you can't do it through the config tool), so it would have to be something I'd add to a future version.  So hopefully you can solve it with a little reconfiguration of whichever device is conflicting.

Thanks for the reply mjr,

Will try that out again and see which one(s) are causing the problem.

Lovin' the pinscape controller w/ the optical Lin. array works awesome (in Future Pinball).  Just wish VP had similar settings like FP.

 

Guessing there's no way of 'forcing' Visual Pinball to use the Pinscape controller in the registry?

 

thanks again,

thomas

[mjr]

Thanks for the reply mjr,

Will try that out again and see which one(s) are causing the problem.

Lovin' the pinscape controller w/ the optical Lin. array works awesome (in Future Pinball).  Just wish VP had similar settings like FP.

 

Guessing there's no way of 'forcing' Visual Pinball to use the Pinscape controller in the registry?

 

I don't think so - VP lets you select which axis you want to use, but I don't think there's any way to select a specific device if multiple devices are reporting input on the same axis.  It would be a good improvement in VP to be able to select a specific device rather than just the axis.

[monza]

I'm using V2 software and the issue I'm having as that when I pull the plunger it starts off really slow (ie 10mm of real plunger pull moves the virtual plunger about 2mm) and then 'speeds up' to the point where after about 30mm then it gets closer to 10mm real to 10mm virtual. Is this just something to avoid a bit of jitter when the plunger is at rest? Or is this because VPX is setup for a key press plunger so it is hard coded to accelerate up to speed?

 

Other issue is that I find that half a plunge pull on the real and already the virtual is beyond the little window... shouldn't a full pull still show the tip in the virtual?

 

Please note these are small little issues in an otherwise great product. 

Edited by monza, 07 July 2017 - 04:40 AM.

[DDH69]

A quick note for fellow Pinscape users.  I have now added native support for Pinscape to DOFLinx using mjr's and rambo3's branches of the Direct Output Framework (hopefully to come together soon).  I don't want to derail this great support thread with DOFLinx discussion.  If you're interest, have a read over here.

[kiwiBri]

I'm using V2 software and the issue I'm having as that when I pull the plunger it starts off really slow (ie 10mm of real plunger pull moves the virtual plunger about 2mm) and then 'speeds up' to the point where after about 30mm then it gets closer to 10mm real to 10mm virtual. Is this just something to avoid a bit of jitter when the plunger is at rest? Or is this because VPX is setup for a key press plunger so it is hard coded to accelerate up to speed?

 

Other issue is that I find that half a plunge pull on the real and already the virtual is beyond the little window... shouldn't a full pull still show the tip in the virtual?

 

Please note these are small little issues in an otherwise great product. 

 

 

Yes, on a Full pull you still see the plunger tip. (Well I do) 

What sensor are you using for the plunger? I believe your results are going to be reflective of the type of sensor. Some are less linear than others in their results back.  Jitter correction may also help a little 

A quick note for fellow Pinscape users.  I have now added native support for Pinscape to DOFLinx using mjr's and rambo3's branches of the Direct Output Framework (hopefully to come together soon).  I don't want to derail this great support thread with DOFLinx discussion.  If you're interest, have a read over here.

 

Thanks!  I look forward into this as soon as I warp up my Pinscape Night Mode issue!  My Cab is pretty much done. 

[mjr]

I'm using V2 software and the issue I'm having as that when I pull the plunger it starts off really slow (ie 10mm of real plunger pull moves the virtual plunger about 2mm) and then 'speeds up' to the point where after about 30mm then it gets closer to 10mm real to 10mm virtual. Is this just something to avoid a bit of jitter when the plunger is at rest? Or is this because VPX is setup for a key press plunger so it is hard coded to accelerate up to speed?

 

I can think of two possibilities:

 

1.  You're using an audio-taper potentiometer.  You didn't say what kind of sensor you're using, but if it's a pot, it needs to be a "linear taper" type.  The behavior you describe would occur if you use an "audio taper" type, which has a logarithmic resistance curve, which would produce the kind of response curve you're seeing with varying speed across the pull range.  If you're using an optical sensor, this obviously isn't the issue.

 

2.  You might have run the Windows joystick calibration.  The Windows calibration is bad for plungers; don't use it.  If you might have accidentally run it in the past, you can delete the calibration as follows:

 

Bring up the Start menu search box or Press Windows+S

Type "set up usb game controllers" into the box

Click on "Set up USB game controllers" in the result list

Double-click "Pinscape Controller" in the list

Click on the "Settings" tab

Click "Reset to default"

 

 

Other issue is that I find that half a plunge pull on the real and already the virtual is beyond the little window... shouldn't a full pull still show the tip in the virtual?

 

I'm not sure what you mean - are you talking about VP or the Pinscape Config Tool?  

 

If you're talking about VP, then what "should" happen is entirely up to the particular table you're playing.  Different tables have different plunger animations.  Some of these animations can show the plunger pulled back all the way, others can't.

 

If you're talking about the Pinscape Config Tool, you might just need to run its calibration.  (Note: this is completely different from the Windows joystick calibration that I was talking about above.)  Run the config tool and click on the Plunger icon.  Click the Calibrate button and follow the on-screen instructions.

[rickh]

Mike (AKA MJR),

 

 

Thank you so much for all your contributions to visual pinball.  I am embarking on my 3rd cabinet and it would be doubtful I would have ever been interested without your innovative work on Pinscape.  BTW -I am currently researching an alternative solution to the plunger sensor using an Adafruit VL6180X Time of Flight Distance Ranging Sensor (VL6180).  This solution is slightly more expensive than the linear potentiometer, but should offer the same performance as the your CCD array at half the price.  Provisions for I2C interface and applicable coding would need to be mitigated.   As such, I can send you a  VL6180 eval PCBA for development.   Let me know if you would be interested.

 

Thanks again,

 

Rick 

[mjr]

Thank you so much for all your contributions to visual pinball.  I am embarking on my 3rd cabinet and it would be doubtful I would have ever been interested without your innovative work on Pinscape.  BTW -I am currently researching an alternative solution to the plunger sensor using an Adafruit VL6180X Time of Flight Distance Ranging Sensor (VL6180).  This solution is slightly more expensive than the linear potentiometer, but should offer the same performance as the your CCD array at half the price.  Provisions for I2C interface and applicable coding would need to be mitigated.   As such, I can send you a  VL6180 eval PCBA for development.   Let me know if you would be interested. 

 

As it turns out, the software already supports the VL6180X!  I added it a few months ago when I was investigating alternatives to the TSL1410R when the supply of those dried up.  See http://mjrnet.org/pi...php?sid=vl6180x.

 

Unfortunately, the VL6180X isn't very good in terms of accuracy or stability.  It's better than the similar analog IR sensors used in the older commercial kits, but not better enough to be a really good option.  The two main problems are that it's really slow (it takes about 15ms to get each fix, which is too slow given that the plunger moves by nearly its whole length in that time when released), and its true accuracy is only about +/- 1cm.  (Its precision is 1mm, but this is one of those cases where there's a big difference between precision and accuracy.)  The software can deal with the slow reading time, but the 1cm accuracy is a pretty fundamental limitation.  The "jitter sensor" option in the firmware helps, but the cost is that you sacrifice a lot of precision, since it filters out the large amount of noise by treating readings that fall within the (adjustable) jitter window as the same position.  On the plus side, this sensor is relatively cheap and quite easy to set up, so it could still be worth a try.

 

There's also a whole new optical sensor option if you haven't seen that yet: http://mjrnet.org/pi...hp?sid=aedr8300.  It works nicely, and it's cheaper than the TSL1410R was, but it's quite a lot more complex to set up.

Edited by mjr, 19 July 2017 - 02:44 AM.

[rickh]

MJR,

 

Thanks for the reply.  I see you covered the performance of the VL53L0X, which I failed to mention.  That linear encoder is a brilliant idea!  BTW- I designed a Mezzanine PCBA that piggybacks on top of the KLZ25. This PCBA was inspired by your efforts,as I liked what you did, but I didn't need all the features. So I limited my data out as 16 channels of buffered output for LED Wiz (100 ma per Ch), three Power MOSFETs for activating solenoids and such, button input connections, and connections for a plunger linear pot.  I will make another revision to include both the I2C for the VL6180 and the DIO for the Linear encoder.  I designed this PCB using Express PCB and would be thrilled to share the files with you and this group as my gratitude to everyone's contributions.     

 

Thanks again,

 

Rick

[rickh]

MJR,

 

I am modifying my PCB for the linear encoder and noticed that you are using PTD0 and and PTD5, both 2 of 10 PWM channels.  I guess the quadrature inputs needs to be high speed?

 

Regards,

 

Rick 

[STV]

AEDR8300 FTW.  Seriously.  If you have any tinkering ability at all it's the way to go.  If I don't make the skill shots now I can't blame it on the plunger...  

 

FWIW rickh I moved the chA and chB for the AEDR8300 to PTD0 and PTD2 respectively, not sure whether that factors in to your high speed question.

[rickh]

STV,

 

Thanks for the reply. I am giving up on the VL6180, as it doesn't have the performance needed according to Mike.  My concern about the AEDR8300 is that it used I/Os two of only 10 channels that were PWM compliant for LED Wiz. If I am mistaken please correct me.

 

Rick

[mjr]

Thanks for the reply. I am giving up on the VL6180, as it doesn't have the performance needed according to Mike.  My concern about the AEDR8300 is that it used I/Os two of only 10 channels that were PWM compliant for LED Wiz. If I am mistaken please correct me.

 

The inputs on the AEDR8300 can actually go to any PTAxx or PTDxx pin.  I chose the two ports used in the defaults because they were free in the expansion board configuration, but you can change them for non-expansion board use.  (The expansion boards don't need as many PWM channels because they use the TLC5940 chips to add new PWM outputs beyond the KL25Z's limited set.)  

 

The reason you have to use PTAxx or PTDxx ports is that those are the ones where the KL25Z hardware supports interrupt requests.  The AEDR8300 signals are extremely rapid during fast plunger motion (about 30us between pulses at the fastest plunger speeds), and the only way for the KL25Z to keep up with input that fast is to process it via hardware interrupts.  Fortunately, the KL25Z has lots of interrupt-capable ports, so the pin assignments are pretty flexible.  Which is nice given how limited some of the other functions (like PWM) are in terms of pin assignment options.

Thanks for the reply. I am giving up on the VL6180, as it doesn't have the performance needed according to Mike.  

 

I think that's the right call.  The only reason to consider it is that it's fairly easy to set up, but the potentiometer option is about equally easy and works much better.  I think the AEDR8300 is the best option in terms of performance, but it's a pretty big jump in complexity to set up.

[rickh]

MJR,

 

Thanks for all the technical details, you are so awesome!!!  One of the reasons I picked this project was to get back into C programming (specifically C#), as I have been using LabVIEW for the last 15 years and my new job is driving me away from my comfort zone in mixed signal into software.

 

Thanks again,

 

 

Rick