1103 replies to this topic

[mjr]

I was reading the forum and believe I have confused myself.  I have soldered the Main board and Power board and am ready to start putting things together.  I wanted to reach out though as I am unclear if I need to worry about fuses when I am hooking everything up to the power board?  If you could help me out that would be greatly appreciated.

 

Here's the build guide section, which includes advice on which devices are most important to fuse.

 

http://mjrnet.org/pi...e.php?sid=fuses

 

Quick summary:  I'd include them for higher-power inductive devices, especially motors and larger solenoids.  You can skip them for LEDs and incandescent lamps.  They're nice to have but not too necessary for middle-power devices like contactors.

[Cameron]

Alas... I have done something wrong and need help! 

 

OK so here is my current setup. 

I had completed the Pinscape expansion board. I was only using it for button inputs and it has been working really well.

I finally got around to installing the power board with some 12V solenoids, a shaker, and a beacon attached.

 

I wired the PC power and the secondary power to both boards. All PSU negatives are connected to common block. 

All of the negatives (of the output devices) are wired down to the power board and the positive are connected to a fuse block.(I have diodes for each device as well)

 

I pulled up the Pinscape software and was eager to test a device.... I went through trying to turn things on and nothing happened.

 

I pulled up the setup section in the Pinscape software. As I was scrolling down, I noticed that there was a section for output that wasn't turned on (I am sorry I don't remember what it was called exactly because I can't get back there). I went in and turned on bank 0. I then went and uploaded it to the Pinscape controller. 

 

The controller never came back... Nothing happens if I plug in or unplug the USB cable. No lights nothing. Reset button doesn't do anything either. 

 

If I switch the cable to the "programming" side, I get a green light so something is still alive in there. 

 

So perhaps the update killed off the Pinscape? How does one recover from this? What am I doing wrong???? Any help would be greatly greatly appreciated! 

[mjr]

Cameron - It sounds like something got corrupted in the firmware memory.  Fortunately the KL25Z has an extremely robust design that makes it almost impossible to brick with software problems, because the USB firmware programmer section is completely isolated from the software side.   You can basically always start from scratch with a new firmware install.

 

The first thing I'd try, though, is removing the KL25Z from the expansion boards, so that it's not connected to anything but USB.  Try plugging it in to USB like that to see if anything changes.

 

If it's still looking dead, try doing a full firmware reinstall.  Keep it unplugged from the expansion boards and everything else, then do this:

 

- Plug in USB on the programming side

 

- Bring up the Pinscape config tool

 

- Click on "Set up a new KL25Z"

 

- Go through the steps to re-install the firmware

 

If you can't get it to recognize via USB on the programmer side, or it's still dead after a fresh install, something deeper might be wrong, like maybe some hardware damage.

[Cameron]

OK I disconnected the power board and flashed the firmware. It has come back alive so that is great. Thanks for the guidance!

That is all I could do before heading out to work. Tonight I will try to set things up again. Hope it works this time.

[Cameron]

I'm Baaaaaaack. 

 

OK so I am now graduating to high voltage. I have a 48V PSU installed in the cab and have it wired to the Knocker pin on the expansion board.

 

So... I wired everything up and loaded the Pinscape config software. Went to the output tester page/application and hit on for the knocker port. The solenoid fired gloriously.... and then it stayed on.

I couldn't toggle it off with the output tester or anything. I pulled the power so I wouldn't have a meltdown....

 

I shut down the output tester and now 100% of the time if I connect the wiring to the solenoid, it is on and stays on. 

 

I tried changing the 0 volt parameter in the config to the other position. No change. Changed it back, no change. I thought I might have a short so I unplugged the ground from the Pinscape expansion and it stopped so basically the knocker timed port seems to be stuck on permanently. I could switch the output over to the big power board, but then I lose that valuable timer circuit. I really want that with the 48V solenoid. 

 

If all else fails, maybe it is time to assemble my chime board and use it for the knocker?

 

Any help is def. appreciated!!!

[Cameron]

Well I think something really bad is happening here.... 

 

I think that maybe there is too much power going through the board and it can't handle it. No matter what I do, the Knocker output is stuck to where current just flows through. I thought that I would test it out on my expansion power board as well. 

The second that I activated that port, the same thing happened. The port on the expansion power board is also permanently stuck closing the circuit. 

I haven't flashed the firmware again, but have reset the controller and cycled the power on every power supply etc... 

It is still stuck. I guess it has fried that port, both on the knocker and on the power expansion board. 

 

Any ideas as to what has gone wrong? I will say the PSU is 48V not 40V. Is that too high? (probably yes). I think the other thing that I could do going forward is use the Pinscape to operate a relay and take this mega PSA out of the regular circuit path.

 

I imagine that it is one component on the circuit board that is fried. Any suggestions as to which one so I can replace? I still want the knocker timeout functionality even with the relay so I don't burn out the coil or burn the house down etc.

[mjr]

Cameron - pretty clearly something got zapped on the board.  The 48V supply should be okay in principle, assuming you're using one of the MOSFETs on the list, but that is pushing it a bit.  The FQPxxN06L series is rated for 60V, and the BUK7575 is rated for 55V, so you're within the safe zone if you're using one of those, but there's not a ton of margin.

 

You did connect your 48V supply's ground to all of the other power supply grounds, right?

 

And you have a diode on the knocker coil, right?  

 

My guess for the broken part is the MOSFET.  I think the common failure mode for overloaded MOSFETs is to short across the channel, which is consistent with what you're seeing.  If you'd fried something else, or if one of the PCB traces melted, the port would probably be stuck off instead.

 

So you could try replacing the MOSFET.  You might want try a different MOSFET rated for higher voltage - maybe try something rated up to 75V or 100V. 

Edited by mjr, 02 November 2018 - 06:22 PM.

[Cameron]

Thanks for the information!

I ordered the original mosfets from the list. I do have a diode on the knocker coil. I also have the 48V PSU ground connected to the other power supply grounds. I did check the voltage output and it was right at 48V. Maybe it is spiking under load? 

 

I just ordered some 100V and a 75V MOSFET to try again. Hope it is just the MOSFET that is blown. I would think so since everything else seems to be working. 

 

I was going to use that 48V to run the chime unit in the future so I need to get this worked out... On a negative note, the 48V PSU is louder than I would like!

[Cameron]

Swallow sadness  

 

OK picked up some 100V MOSFETS and removed the original MOSFET from the expansion board. 

Plugged everything back in and the second that I plugged the 48V PSU back in the solenoid turned on.... 

 

I didn't check to make sure the rest of the functionality was OK before plugging in the High voltage PSU...

 

Looks like the Freescale board is toast. Right now if I plug it in to just USB alone, the processor chip gets super hot very fast. Same goes when plugging into the programming port. The green LED flashes and the processor gets hot to touch in seconds. So... something is hosed. 

 

I need to pick up another main board (or two)... 

 

Still not sure what went wrong exactly. Not sure it really was the MOSFET dying. Maybe something else. 

 

I am a bit worried that my expansion board has some compromise that will fry the next Freescale board. I suppose that the worst would be frying another board to test it.... Wish they were slightly cheaper boards lol

[Cameron]

OK so today with the help of a friend, I changed another kl25z board that I had to have the female header setup to match the expansion board. 

We also replaced the MOSFET on the Expansion board with a replacement one (from my unbuilt chime unit).

 

The new Freescale board accepted the latest firmware and my config. and after plugging in everything, The kl25z seems to be doing OK as I now have button inputs coming in from the controller. 

 

On a really sad note, I am getting nothing from any high power outputs. After doing my configuration, I go to the output test tool. Nothing activates. 

 

I checked the 5v coming from the PC PSU and it is good. My 5v and 12v aux power are also good coming into the expansion boards. 

I haven't checked my ground distribution block nor my positive power fuse blocks (other than to make sure no fuses were blown). 

 

Something bad/scary made its way back to the old Freescale board and fried is... I wonder if it took out some others (ICs) on its way there?

 

Not totally sure how to trace out which things would work and which wouldn't... I was soooooooo close!!!!! 

Had 10 solenoids going, beacon, shaker, blower. Now I'm back down to just input buttons working. Was looking forward to addressable LED strips.... 

 

IF I can't get to the bottom of this, I guess I can start building again.... It was super-fun to build the boards, but I think it will be sad if I have to do it again. 

I don't know if I will ever hook that 48V PSU to anything Pinscape directly... Will probably do relays to keep it isolated from the other stuff. 

[mjr]

OK so today with the help of a friend, I changed another kl25z board that I had to have the female header setup to match the expansion board. 

We also replaced the MOSFET on the Expansion board with a replacement one (from my unbuilt chime unit).

 

The new Freescale board accepted the latest firmware and my config. and after plugging in everything, The kl25z seems to be doing OK as I now have button inputs coming in from the controller. 

 

On a really sad note, I am getting nothing from any high power outputs. After doing my configuration, I go to the output test tool. Nothing activates. 

 

I checked the 5v coming from the PC PSU and it is good. My 5v and 12v aux power are also good coming into the expansion boards. 

I haven't checked my ground distribution block nor my positive power fuse blocks (other than to make sure no fuses were blown). 

 

Something bad/scary made its way back to the old Freescale board and fried is... I wonder if it took out some others (ICs) on its way there?

 

Given that none of the outputs are working, there might be some physical damage to the PCB somewhere.  You might want to get out a magnifying glass and look over the copper traces to see if you can spot any burn marks or other signs of damage.  Also double-check the power connections.  If possible, check with a voltmeter that the power connections are all reading at their expected voltages.

 

The reason I suspect PCB damage is that most of the active components have more limited scopes than "all outputs".  Damage to a single chip, transistor, or other component would usually be isolated to either a single output or a group of outputs.  The worst case would be to damage one of the TLC5940 chips, which would take out all 16 outputs it controls - but that would still only be 16 outputs.  If nothing is working, I'd suspect that a ground or power trace somewhere got fried.

 

 

 

I don't know if I will ever hook that 48V PSU to anything Pinscape directly... Will probably do relays to keep it isolated from the other stuff. 

 

For what it's worth, the 48V *probably* wasn't the problem per se.  All it would take to fry the KL25Z would be 5V connected to the wrong wire.  So I wouldn't worry specifically about 48V - 5V or 12V could be just as bad if there's a short or bad connection somewhere.  It's possible that the high voltage triggered some cascade of problems that started with frying the MOSFET and working backwards through the circuitry, but the KL25Z is actually pretty well isolated on these boards.  There's an optocoupler between every high-voltage sub-circuit and the KL25Z, and the optocouplers are supposed to block faults of up to about 5000V.  So 48V really shouldn't even begin to make a dent at that barrier.  So... what seems more likely is that there was some more general fault, like maybe a power spike through the power lines, or more likely, one of the non-high-power pins on one of the boards got connected to power briefly.  What's *not* protected on these boards is all of the logic inputs - the buttons and plunger inputs, for example, connect *directly* to the KL2Z GPIOs, so a fault on those (e.g., briefly connecting one of them to +12V) is likely to fry the KL25Z.

[STV]

 

 or more likely, one of the non-high-power pins on one of the boards got connected to power briefly.  What's *not* protected on these boards is all of the logic inputs - the buttons and plunger inputs, for example, connect *directly* to the KL2Z GPIOs, so a fault on those (e.g., briefly connecting one of them to +12V) is likely to fry the KL25Z.

 

 

I..  uh..   did this.   more than once.    Thought maybe it was just that one output that fried.   But flakiness ensued after the momentary accidental wire touching...   Then the accelerometer stopped working.     That's when I started buying more than one KL25Z at a time...     And the mosfets too.  I'm melted several of them closed in the past few months tinkering around with the power on.

[Cameron]

I def. did the board check with magnifying glass. I don't see any physical damage. 

Can't smell any evidence of burnt components, but that doesn't mean too much. I figure maybe I didn't just fry the kl25z, but every IC on the boards? 

I know whatever it is, it is something that I did stupidly lol... 

 

I think I will order another backup board set and components and build another one. It will take some time for the stuff to get here.... In the meantime, I will see what I can diagnose with my limited skills. 

 

While I am waiting for parts and stuff I can finally work on my addressable LEDs again! 

[Fusionwerks]

MJR, i am currently trying to figure out an issue that has just randomly started happening, and i need your help guiding me to troubleshooting it.

 

Here is what it is doing:

 

My Right outside RGB flasher intermittently stays on. Sometimes, when i start a table, it will flash, then it will stay lit red until i start the game, then it acts normal. Sometimes after a game is over it will stay lit red, and even after i exit the table it will be on. It only shuts off when i launch another table. I have a few tables that it will come on every time at startup (and never did before or is supposed to be on)

 

Here is what i've tried:

 

I have tried to reassign the outside right flasher to the right flasher in the DOF config tool. The problem stayed with the outside right light..

I have tried to swap the wiring of the lights, and the problem follows whichever light is plugged into the first RGB ports

 

So i've narrowed it down to the fact that it is a problem on the first RGB ports, but do you know whats causing it? Or how to troubleshoot further?  

[mjr]

Fusionwerks - those are good tests; I agree that points to something wrong with the port at the hardware level. 

 

However... the way that starting or exiting a table tends to turn it on or off sounds more like a software problem on the PC side.  You wouldn't expect entering or exiting a game to have any effect if this were a hardware problem, because the hardware doesn't know anything about that.  Here's the way the firmware works with the TLC5940 chips:  about every 12ms, the firmware sends a complete update to every TLC5940 chip.  Regardless of whether anything has actually changed at the software port level.

 

So the symptoms taken together are pretty baffling.  The only thing I can think of that could be hardware-related - and this is really wild speculation - is that maybe the opto on that channel has developed some kind of bizarre hysteresis issue where it gets stuck on or off after a level change on its input. 

 

 

We're talking about the port labeled "1R" on JP11 on the main board, right?

 

Did you socket the PC847 chips?  If so, you could pretty easily test my wild guess about the flaky opto by swapping OK1 and OK2.  If there's something wrong with the opto, you'd see the behavior migrate to JP11 2G (green port on flasher 2).

 

 

Another thing you could try is exercising the port from the output port tester in the Pinscape Config Tool, to see if you can turn up any other patterns to the behavior with a more direct test of the ports, without the layers of VP and DOF software involved.  It might be useful to play with that a little and see if it shows any anomalies there.  One thing to try is just repeatedly turning it on and off and changing the brightness, and see if the LED responds correctly or if it misses some signals.  Another thing to try is to fiddle with the other ports (again, repeated on/off and brightness changes), to see if any signals are getting crossed with 1R - 1R obviously shouldn't be affected by what other ports are doing.

[Fusionwerks]

well i did all the tests you suggested, and i get no strange behavior by testing the ports or other ports. I did socket the chips, but i don't know if i'm ready to try to pry them out quite yet. I started thinking about what you said that it is probably software related, and it does make sense that one doesn't know what the other is doing.. SO, i tested loading tables in VPX, and VP9X, and physmod, and when the table is just about to finish loading i ALWAYS get a quick flash from that flasher, and sometimes it stays on depending on the table. So this leads me to believe that it is NOT VP, but something else. I just finished doing a complete refresh of everything in my cab, so i am running all the latest everything. I am a bit apprehensive about trying to revert to older software revisions as a test, but i just don't know which one i should start with. Do you have any other suggestions as to which software you think might be the culprit? I just don't know enough of whats going on behind the scenes, and what communicates with what.

 

I wouldn't worry about it, but i'm afraid that one day my wife or kid will walk away with it stuck on, and the flasher will overheat and eventually burn up

 

Maybe the quick flash is/has always been there and i just have never noticed? Can anyone else confirm or deny that the outside right flasher shows a quick flash at every table startup?

Edited by Fusionwerks, 09 November 2018 - 06:10 PM.

[Fusionwerks]

Update:

I have tried running the DirectOutputConfigTester and loading a table file and ROM, and i get the same weird behavior. The light comes on and stays on

 

I have also tried to revert to the 2016 and 30 Aug 2018 release of the Grand Unified, with no change, light comes on and stays on. tried the 2016 stable release, but i cant get it to work at all

Edited by Fusionwerks, 09 November 2018 - 07:09 PM.

[mjr]

Fusionwerks - that behavior of the one channel flashing on at every table load definitely isn't normal.  

 

Here's another test.  Go into the Pinscape Config Tool and reassign the problematic port (in the Output Ports list) as "Virtual Out".  That will leave the software port in place for DOF and everything else on the PC side, but the on/off/brightness signals that the PC sends will just be ignored on the KL25Z side.  ("Virtual Out" means that the software port isn't connected to any hardware.)  Then you can go try the VP tests again and see if the port turns on.  If the problem goes away, I'd say it's definitely a software problem on the PC side - almost certainly something in your DOF port setup.  If the problem persists, it would rule out DOF, because there should be no way for DOF to get a signal through the KL25Z to the hardware port with the port remapped to Virtual.

[Fusionwerks]

ok, so here goes....if i assign the port 1 (jp11-2) to "Virtual" the light will still flash green but not stay on. If i set port 2 (jp11-4) to "virtual" as well, it will not blink at all. If i assign any other light to port 1 it will continue to follow the same behavior, same with assigning to port 2. 

With that said, do you think that there is something wrong with the ports 1-2? If so what do you think i can do about it? Maybe its time to try swapping the octos?... NOPE, I swapped the 847 chips on OK1 and OK2 and no change.

Edited by Fusionwerks, 09 November 2018 - 09:50 PM.

[mjr]

ok, so here goes....if i assign the port 1 (jp11-2) to "Virtual" the light will still flash green but not stay on. If i set port 2 (jp11-4) to "virtual" as well, it will not blink at all. If i assign any other light to port 1 it will continue to follow the same behavior, same with assigning to port 2. 

With that said, do you think that there is something wrong with the ports 1-2? If so what do you think i can do about it? Maybe its time to try swapping the octos?... NOPE, I swapped the 847 chips on OK1 and OK2 and no change.

 

 

Just to double-check that I'm picturing things correctly, here's what I think your physical wiring to the problematic LED looks like:

Port 1 = JP11-2 / "1R" = RED channel of the misbehaving LED

 

Port 2 = JP11-4 / "1G" = GREEN channel of the misbehaving LED

 

Port 3 = JP11-6 / "1B" = BLUE channel of the misbehaving LED

 

Is that all right so far?

 

If so, I'm pretty sure you just ruled out hardware issues and narrowed it to a DOF issue.  Here's my reasoning:

 

When you set port 1 to Virtual Out, you made the RED channel stop misbehaving, right?  You still see the green flashes.  The green is controlled by port 2, which so far is still connected.  But disabling the red channel made the red channel stop misfiring.

 

Then when you set port 2 to Virtual Out, you also made the GREEN channel stop misfiring.

 

If it were a hardware issue, or a KL25Z firmware bug or configuration issue, turning off the ports at the firmware level shouldn't have made any difference, because whatever electrical problem was going on would still be there.  But turning off the port at the firmware level seems to have totally shut down the misfiring, right?  So I don't think there's any possibility remaining that you've got a crossed wire or anything like that. 

 

And I think you're ruled out my hare-brained theory about bizarre failure modes in the opto.  I guess the same idea could apply to the ULN2064 chips or the TLC5940 chips, so if you've socketed those as well, you do a similar swap - swap IC1 with IC2 and/or swap IC5 with IC6.  But I really don't think it's going to be anything in the hardware at this point, so those swaps probably aren't worth the effort, other than to further rule out hardware issues before directing all your attention to the DOF setup.

 

This is such a strange symptom that I still don't have any good guesses about what could be wrong in DOF.  I don't think I've heard of anything similar before.  If we're going to assume it's DOF, which seems like where things are pointing, the symptoms seem to point to two main possibilities:

 

1.  You have some other DOF device(s) mapped to ports 1 and 2.   Maybe go over your DOF Port Assignments page and see if you can spot anything.

 

2.  There's some other software running - a separate background application, something like that - that's also trying to talk to DOF, or maybe directly to the LedWiz interface, while VP is running.  Try killing all background processes and running VP in isolation, without using any front end.

If all else fails, you could simply abandon the nominal ports 1-3 and remap the LED to a whole new set of ports at the high end of the port list.  Here's how:

 

- Go the Output Port list in the config tool

 

- Set your current ports 1, 2, 3 to Virtual Out.  This will free up the TLC5940 outputs so that you can assign them to different port numbers.

 

- Go down to the very bottom of the output port list.  Click the green "+" button in the blank row at the bottom to add a new row.  Add three new rows this way.  Assign the first row to TLC 5940 Chip 1 port 0, the second row to Chip 1 port 1, the third row to Chip 1 port 2.

 

- Now to go the online DOF config tool and re-assign your Outside Right Flasher to the three newly created port numbers.

 

If the whole problem was something conflicting with the nominal DOF port numbers "port #1" and "port #2", that should move the LED out of the way of the conflict.