1103 replies to this topic

[DDH69]

>  I am unsure if I must have the TV ON item enabled to get it to fire on startup.

 

You do need the TV ON feature enabled, with the power sensing circuit connected and configured.  It's the power sensing circuit that's key here, since that's what triggers it.  You don't need a relay connected, though; you can have IR alone, relay alone, or both.

 

> If so, I can't set the TV ON outputs to not connected and have no free ports for dummy a dummy output.

 

If you're talking about the relay, you can leave that port Not Connected - no GPIO required there.  But you do need the two GPIO ports for the TV ON power sensing circuit.

 

If you don't have enough ports for the power-sensing circuit, you might be able to make it work by manually sending the IR commands through the command-line tool, triggering it from a Windows startup script or something along those lines.  That should work as long as it's okay for the TV to turn on after Windows finishes booting.

 

PinscapeCmd SendIR=1 Quiet as a startup shortcut = Perfect, thanks.  Had never used that before!

[Fusionwerks]

MJR,

I have been having problems with my plunger (AEDR-8300). It does not behave the way it is supposed to anymore. The plunger PHYSICALLY works correctly, but it is being read incorrectly.

Sometimes it only plunges half strength (when pulled all the way back and released)

Sometimes it just fires it full strength (when you barely pull it back without letting go)

Sometimes it does something completely different in between... LOL

 

I have the latest firmware, and I have run the calibration in the Pinscape Config tool with no change. However you can clearly see that it isn't working right. (See Video Here)

Attached is a capture from the joystick capture tab in the Pinscape Config tool. (These were captured separately from the video above)

Let me know if you see something wrong, or what I need to provide for you to help me figure this out.

My skill shots, and my scores are suffering! I'm hoping you can assist me. Thanks again for all you do!

 

 plunger capture.txt   7.1KB   4 downloads

 

[mjr]

Fusionwerks - it would good to try reverting to an older version of the firmware to check if it's a problem in the firmware or a problem in the hardware.  If it acts the same way with older firmware, it's likely a hardware issue; if reverting fixes it, it's probably something wrong in the newer firmware. It would be good to know which to determine how to proceed.

[Fusionwerks]

Fusionwerks - it would good to try reverting to an older version of the firmware to check if it's a problem in the firmware or a problem in the hardware.  If it acts the same way with older firmware, it's likely a hardware issue; if reverting fixes it, it's probably something wrong in the newer firmware. It would be good to know which to determine how to proceed.

I had the problem before I upgraded the firmware and after I did. I don't remember the version I was on.

 

So it would seem to be hardware related. What do you suggest I try next?

 

Edit: If it helps, the graphical representation of the virtual plunger mimics the behavior of the calibration screen in the video. Sometimes the plunger appears to be pulled half way back when it is not.

Edited by Fusionwerks, 06 December 2024 - 12:46 AM.

[mjr]

> I had the problem before I upgraded the firmware and after I did. I don't remember the version I was on.

 

It might still be worth trying an older version, just to be sure. Recent changes (in the 2024 releases) do affect the plunger calculations, so it's possible there's some problem there that I haven't caught yet.  I'd go back to the 12/22/2021 version, since that was stable for a long time.

 

http://mjrnet.org/pi.../swversions.php

 

(Scroll down to the Archived Release Builds section.)

 

If it's a hardware problem that developed spontaneously, there are two main areas I'd look at.  The first is the wiring connections - maybe one of the connector contacts is getting flaky from oxidation or has gotten loose, or a solder joint has cracked.  Just melting the solder at the joints sometimes fixes that sort of thing, and reseating the connectors might also help.  The second is the optics, since this is an optical sensor.  Maybe the bar-code scale has gotten scratched up a bit and the sensor is having a harder time reading it.  There could also just be accumulated plastic dust on it from wear.  Maybe try taking it apart and cleaning everything, and inspecting to see if there's any obvious wear.

If you're using a laser-printed transparency film for the bar scale, you could also just try printing a new one, in case the image has faded or the plastic has clouded.

[Fusionwerks]

> I had the problem before I upgraded the firmware and after I did. I don't remember the version I was on.

 

It might still be worth trying an older version, just to be sure. Recent changes (in the 2024 releases) do affect the plunger calculations, so it's possible there's some problem there that I haven't caught yet.  I'd go back to the 12/22/2021 version, since that was stable for a long time.

 

http://mjrnet.org/pi.../swversions.php

 

(Scroll down to the Archived Release Builds section.)

 

If it's a hardware problem that developed spontaneously, there are two main areas I'd look at.  The first is the wiring connections - maybe one of the connector contacts is getting flaky from oxidation or has gotten loose, or a solder joint has cracked.  Just melting the solder at the joints sometimes fixes that sort of thing, and reseating the connectors might also help.  The second is the optics, since this is an optical sensor.  Maybe the bar-code scale has gotten scratched up a bit and the sensor is having a harder time reading it.  There could also just be accumulated plastic dust on it from wear.  Maybe try taking it apart and cleaning everything, and inspecting to see if there's any obvious wear.

If you're using a laser-printed transparency film for the bar scale, you could also just try printing a new one, in case the image has faded or the plastic has clouded.

after seeing the release numbers i do remember that the 12-21 version was what I was on, So i can probably rule that out. I will take a closer look at the hardware. I have suspected it might be the transparency strip, but i have a few extra i printed out back in 2017. I will let you know

[Fusionwerks]

ok, so here's an update, but true to any virtual pinball problem, you fix 1 thing and something else stops working...

 

For the plunger:

I rolled back the firmware with no change in the plunger. Then updated back to the 10-24 release.

I then took the plunger apart and inspected all the parts for wear, nothing

The bar scale looked fine, so I didn't suspect anything, but since I had an extra, I decided to swap it anyway. Turns out there was a very fine layer of dust between the transparency and the acrylic mirror.

I cleaned it real well, attached the new bar scale, and re-assembled, and re-calibrated, and it is all back to working perfect. You couldn't see the micro layer of dust between the 2 pieces, but apparently the quadrature sensor sure could!

 

Then I went to play a few games with my "new" plunger and noticed some of my DOF devices were not working as before. Specifically my under cab LED strips, topper LED strips and topper motor (piggybacked off the gear toy). Since I was playing games with KNOWN effects, I found it odd. I checked that they work in the Pinscape config tester, and they were all OK. I updated my DOF, re-downloaded table configs, rebooted, etc... and nothing. Then I reverted the KL25Z firmware back to the 12-21 release, and everything worked again. So it does all technically work now (and before I started screwing around with the plunger today), but maybe is there a glitch in the 10-24 release? 12-21 works, and I'm fine with that, but if I found a bug, and can help you, let me know.

 

Thank you for helping me MJR

Edited by Fusionwerks, 06 December 2024 - 02:47 AM.

[mjr]

> You couldn't see the micro layer of dust between the 2 pieces, but apparently the quadrature sensor sure could!

 

Glad that did the trick with the plunger!  Yeah, those sensors are definitely much less forgiving than human eyes about contrast.

 

> Then I went to play a few games with my "new" plunger and noticed some of my DOF devices were not working as before.

 

If you have the time to do some more testing, it would be good to get to the bottom of it, in case it is a bug in the newer firmware.  You say that the output ports are working in the config tester, so my suspicion falls on DOF.  In particular, the new Pinscape firmware changed the USB interface in such a way that it broke the old DOF Pinscape driver (due to a bug, not an incompatibility per se).  So you definitely need the latest DOF with the latest firmware.  Did you get DOF from my site?

 

http://mjrnet.org/pi...ll-updates.html

 

If you did, then let's take a look at the DOF log file to see if it's reporting any errors, and hopefully that'll either explain it or point to the next thing to try.

[Fusionwerks]

After installing the DOF from your site, and updating to the 10-24 firmware, everything is working good. It had been a long time since i have done any updates on my cab, so  I suspected it was something I did wrong, not a bug in your firmware.

BUT... since its been so long... am i correct in understanding that i no longer need separate directoutput -x86 and directoutput -x64 folders anymore? I followed your directions, and downloaded and installed BOTH msi's to my directoutput - x64 folder. Then i updated my table configs from the DOF site and copied them into the x64 folder.

Can I now delete the x-86 folder?

Do i ONLY need to update the x64 folder with new DOF table mappings?

[mjr]

After installing the DOF from your site, and updating to the 10-24 firmware, everything is working good

 

Great!

 

 

BUT... since its been so long... am i correct in understanding that i no longer need separate directoutput -x86 and directoutput -x64 folders anymore? I followed your directions, and downloaded and installed BOTH msi's to my directoutput - x64 folder. Then i updated my table configs from the DOF site and copied them into the x64 folder.

Can I now delete the x-86 folder?

Do i ONLY need to update the x64 folder with new DOF table mappings?

 

You should still have x86 and x64 folders, assuming that you still need both 32-bit and 64-bit versions (which most people do), but not at the "top level" like in the older setup.

 

The OLD way of installing 32 and 64 at the same time was to create two entirely separate DOF folder trees, like so:

 

***OLD WAY (do not use for new setups)***

c:\DirectOutput32  -> run the 32-bit installer, and enter this path in the Setup box where it asks for a folder

c:\DirectOutput64  -> run the 64-bit installer, and enter this path in the Setup box where it asks for a folder

 

So you end up with two top-level folders containing separate, complete DOF installations, one for 32-bit, and one for 64-bit.  Then you had to do some manual fixup that was laid out in various tutorials, which I won't cover here because that's all obsolete now.

 

 

The NEW way, using the installers from my mjrnet.org site, has a single "root" folder where all of the config files go, and inside that, two subfolders (x86 and x64) containing the respective 32-bit and 64-bit binaries.  In the new setup, the install procedure is similar but simpler:

 

***NEW WAY***

c:\DirectOutput  -> run the 32-bit installer, and enter this path in the Setup box where it asks for a folder

c:\DirectOutput  -> run the 64-bit installer, and enter this path in the Setup box where it asks for a folder

 

So as far as SETUP is concerned, you just enter that one combined folder.  If you drill down into the folder with Windows Explorer, you'll see that it contains subfolders for the 32-bit and 64-bit binaries:

 

c:\DirectOutput

  + x86

  + x64

 

You DO still need THOSE subfolders.  But you shouldn't have separate top-level folders any more.  If you ran the install with separate top-level folders for the two bit-ness versions, or you're not sure, you can just delete all of your existing files and re-run the installers the new way to make sure everything's set up the way it should be.

 

The advantage of the new setup is that the 32/64 versions can share all of the config files, so you don't need to replicate those in two places.

Edited by mjr, 06 December 2024 - 06:46 PM.

[roar]

So everything was going swimmingly, things were working well until this evening when I turned things on this evening… one of my chime coils locked on… when I looked inside the cab I saw one of the MOFSETs on the chime board sizzle and smoke, then saw some smoke coming from the chime unit. Turned things off and one of the solenoids on the chime unit is locked on… question… if two of the mofsets were touching each other on the chime board would that be bad? Could that cause a short and the problems I saw? When looking at the chime board the mofsets were touching each other for sure, must have pushied them together the last time I was working around them.

[mjr]

roar - Yeah, you definitely don't want to let the metal fins touch each other.  It varies, but on most TO-220 MOSFETs, the fin is electrically connected to the drain, which is the same pin the solenoid connects to.  So if two come into contact, both loads will be connected to both MOSFETs in parallel, and the MOSFET would get hit with double the current (the sum of current loads for the two devices) if one of them turns on while the other is off.  That might be what caused your MOSFET to blow, or it might have been unrelated, just age or a voltage surge on the power supply or whatever else.

 

In my experience, MOSFETs usually act like reverse fuses when they blow - rather than turning into an open circuit, they turn into a short-circuit to ground.  That's what it sounds like you're seeing.  The good thing is that the short to ground usually prevents any of the solenoid voltage from propagating back beyond the MOSFET, so hopefully the rest of the components on your board are okay, and you can get back up and running just by replacing the MOSFET.  The trick for unsoldering them is to snip off the legs with wire cutters, so that you only have to unsolder one leg at a time - use needle-nose pliers to grab onto the leg and ease it out while you melt the solder.  Once you've extracted the legs, you can use solder wick or a solder sucker to clean up the excess solder enough to insert a new part.

[roar]

Doesn’t sound so bad… I’ll get my hands on a new mofset and solder it on… the solenoid on the chime unit is another thing altogether that thing seems pooched.

[roar]

Looks like the MOFSET in the original BOM is now obsolete on Mouser and DigiKey also doesn’t have any inventory. Is this an adequate replacement? Higher amp rating but the voltage is right. This place also has the hard to find TLC5940 and I could use a few more of those so a good place to buy from and they’re in Canada!

https://abra-electro...rfp30n06le.html

[mjr]

roar - MOSFET substitutions should be no problem, as long as it has high enough voltage and current for your devices and the same pin layout (the pins have to be Gate-Drain-Source in left to right order when looking at the front of the device). 

 

This particular one looks ALMOST good, except that the Absolute Maximum Vgs is too low - the data sheet says Vgs max is +10V.  These boards use 12V for the gate drive, so I don't think this one is safe to use.  Ironically, the 12V gate drive is supposed to make it EASIER to find suitable replacements, since the usual limitation is that large power MOSFETs won't turn on fully unless they have adequate gate voltage.  Many won't turn on fully until they have at least 10V, so the 12V drive was meant to allow a wide range of substitutions.  This one, however, looks like the kind that's specially designed as a "logic" MOSFET, which means it can be driven by low gate voltages - it turns on pretty fully at 3V, so you can drive it from an Arduino.  The tradeoff is that it can't tolerate the higher gate voltages that most power MOSFETs require.  So you should look for a more typical power MOSFET - something with a Vgs[max] in the +20V range.

 

it looks like IRFZ44N on the same site would be a suitable substitute. You should double-check the data sheet to make sure that I didn't miss anything (the pin layout looks good but it's always good to double-check in case I'm being dyslexic today).

[roar]

roar - MOSFET substitutions should be no problem, as long as it has high enough voltage and current for your devices and the same pin layout (the pins have to be Gate-Drain-Source in left to right order when looking at the front of the device). 
 
This particular one looks ALMOST good, except that the Absolute Maximum Vgs is too low - the data sheet says Vgs max is +10V.  These boards use 12V for the gate drive, so I don't think this one is safe to use.  Ironically, the 12V gate drive is supposed to make it EASIER to find suitable replacements, since the usual limitation is that large power MOSFETs won't turn on fully unless they have adequate gate voltage.  Many won't turn on fully until they have at least 10V, so the 12V drive was meant to allow a wide range of substitutions.  This one, however, looks like the kind that's specially designed as a "logic" MOSFET, which means it can be driven by low gate voltages - it turns on pretty fully at 3V, so you can drive it from an Arduino.  The tradeoff is that it can't tolerate the higher gate voltages that most power MOSFETs require.  So you should look for a more typical power MOSFET - something with a Vgs[max] in the +20V range.
 
it looks like IRFZ44N on the same site would be a suitable substitute. You should double-check the data sheet to make sure that I didn't miss anything (the pin layout looks good but it's always good to double-check in case I'm being dyslexic today).

Amazing information and thanks digging for a more suitable replacement! Ill review the datasheet. Fingers crossed I didnt fry more than Mofset.

[roar]

Not sure if I'm reading the data sheet right or not, but the data sheet for the IRFZ44N not have the nice little diagram identifying which legs do what like the other data sheet does, so I'm not sure myself on that front. Max Vgs wise, my read of the data sheet for the IRFZ44N however looks like it is also a 10V max potentially, I'm not great at reading these data sheets clearly .

 

Maybe the FQP27P06 is better? https://www.sparkfun...al/FQP27P06.pdf

Edited by roar, 19 December 2024 - 07:33 PM.

[mjr]

Not sure if I'm reading the data sheet right or not, but the data sheet for the IRFZ44N not have the nice little diagram identifying which legs do what like the other data sheet does

 

It's there, it's just buried way down in the "package outline" section (the mechanical drawing), where they've identified the legs with tiny, tiny digits that I can only read when I blow it up to 381% zoom, and then you have to look over to the weirdly separate LEAD ASSIGNMENTS list on the right.  This data sheet writer is working hard to make sure you can't find the information.

 

 

Max Vgs wise, my read of the data sheet for the IRFZ44N however looks like it is also a 10V max potentially

 

If you look at the ABSOLUTE MAXIMUM RATINGS table (that's the term of art that they always use for the limits), and go down to Vgs row, it says +/- 20V, which is pretty typical for these big TO-220 power MOSFETs.  And perfect for Pinscape boards with their 12V gate drive.

 

The only place I see 10V mentioned with respect to Vgs is in the Id (drain current) rows, where they list "Vgs @ 10V" - is that what you're referring to?  When they use that notation, they're not stating a limit for Vgs, rather, they're telling you the condition under which they measured the other thing that they're actually stating a limit for, in this case Id.  (In this case I won't cast aspersions on the tech writer for the confusing notation, because this is a pretty typical convention.  But you shouldn't feel bad about it either because it really is pretty confusing objectively.  It's jargon that's been reduced by many generations of data sheet writers to this telegraphic format, so you just have to know the code.)

 

 

Maybe the FQP27P06 is better? https://www.sparkfun...al/FQP27P06.pdf

 

That one is a "P" MOSFET, so that won't work.  "P" and "N" MOSFETs are basically opposite polarities for all of the signals, so you can't use a P where an N goes or vice versa.

[roar]

My education continues thank you and yes.. it was those 10V notes i saw I will reread the datasheet to better understand and order some up!

[fhjui]

Looks like the MOFSET in the original BOM is now obsolete on Mouser and DigiKey also doesn’t have any inventory. Is this an adequate replacement? Higher amp rating but the voltage is right. This place also has the hard to find TLC5940 and I could use a few more of those so a good place to buy from and they’re in Canada!

https://abra-electro...rfp30n06le.html

Be careful that this TLC5940 with DIL-Package is not a fake one. This IC in this package has not been produced by TI for a longer time, only in the small SMD package.

You can test for a fake with quite good success: Wipe the top with a tissue or cotton swab with acetone. If the label comes off, it is a fake.

 

Concerning the MOSFET you should pay attention to the Ron of the transistor. If you want to drive a gear motor or shaker motor using PWM, the transistor must have a very low Ron resistance. Your choice with the IRFZ44N with 17 mOhm is rather good.

I would suggest to use an IRFB4310Z with measured 5,5-7 mOhm Ron resistance.

The problem with the MOSFET with the average transistors with 60 mOhm and more is the heatup by the current and the switching losses in the case of PWM.

Edited by fhjui, 20 December 2024 - 11:04 PM.