1103 replies to this topic

[roar]

 

mjr... I've hit another impasse with my flashers. I got the new ULN2064 chips in and have swapped the chips out. That is always a lot of fun, you'd think I'd learn and put sockets in but I forgot to order those again and on they went straight to the board.

I've isolated my 5V's so there is no chance of sending 12V into these chips again and I've swapped out all of my RGB LED's. The problem I'm running into now is that a couple of the lights aren't working. From JP11 R2 and G4 aren't lighting up for me. I have verified that the 5V's is getting to the + side of the RGB. I have verified continuity with my multimeter that the wire that goes to pin G4 is showing up on IC7. I've actually wired B4 up to negative side of the Green light on my RGB and it lights up so I know the LED is good. Is there any steps you could suggest for me to trace the pins from R2 and G4 on JP11 over to IC7 and IC5?

 

I know what you mean about unsoldering - it's a gigantic pain with these big chips with lots of pins.  I know it's not any help for you after the fact, but for future builds, at least, I've added suitable sockets to the parts list for all of the big chips.  I didn't use sockets in my own build either, but I'm starting to lean towards recommending them.  It makes it so much easier to recover from this kind of problem, as well as things like inserting the chip wrong in the wrong orientation when soldering it.

 

Anyway...  Am I correct that all of these outputs were working before that unfortunate 12V cross-wiring happened?  If so, that should at least narrow the number of things to look at.

 

Tracing the circuits, if we start at 2R:

 

  - JP11 pin 8 (2R) goes to IC5 pin 16

  - IC5 pin 14 is the input side of that, connecting to OK1 pin 9

  - OK1 pin 8 is the input side of *that*, connecting to IC1 pin 3

 

I'd check each pair of those for continuity, testing at the actual chip legs on the top of the board rather than the solder pads.  The problem is sometimes a bad solder joint between the pin leg and solder pad that's practically impossible to detect by visual inspection.  Testing continuity at the chip pins can usually catch these.

 

The equivalent for 4G:

 

  - JP11 pin 5 (4G) goes to IC7 pin 9

  - IC7 pin 11 goes to OK3 pin 11

  - OK3 pin 6 goes to IC1 pin 10

 

If all of that checks out, you can try some powered-on tests.  You can remove the KL25Z for these so that you can get to the chips more easily, if necessary.  

 

The first test is to (very carefully!) attach a probe wire to +5V from the secondary PSU - you can use the +5V on JP11 for this.  Then touch the other end of the wire to the Darlington inputs - IC5 pin 14 for 2R, IC7 pin 11 for 4G.  If the respective LEDs light up, the Darlingtons are working.  If not, the problem is probably that those stages of the Darlington chips are dead.  Hopefully not the case given that you just replaced them!!!  But defective chips from the factory can occasionally happen.

 

The second test is a little trickier because you need a resistor to add to your probe wire.  About 1K should work.  Attach the probe wire to the PSU2 ground.  Attach the other end to one end of the resistor.  Then attach a second probe wire to the other end of the resistor, and carefully touch the other end of that probe to the OKn input pins.  For 2R, that's OK1 pin 8; for 4G, it's OK3 pin 6.  This will test the optocoupler.  Again, if the respective LEDs light up, the optos are good; if not, you might have a problem in the respective opto chips.

 

Hopefully you'll track it down with the continuity tests and won't have to go to all that extra trouble!

 

 

I'm still trying to sort this out... took a break for a while as I was/am getting frustrated More so with my VPX tables stuttering than anything else, but back at the Pinscape...

 

Looks like all my RGB's are working except this pesky 4G. I'm not sure if it is my cheap multimeter or not, but I'm not getting the readings I'm expecting. When I set it to continuity my multimeter doesn't have the feature to actually make a sound, it just switches from a 1 to a 001 when I touch the two leads together. When I clip one lead to the  JP11 Pin 5 and then start touching the other leads to the legs on IC7 I get several that register.To be honest I don't know which leg is leg 1. With the notch in the chip, does Pin 1 start to the left of the notch and then criss cross? If that is the case then leg 7, 8, 9 and 10 register 569 while legs 11 register 1198 and leg 15 registers a 002.

Needless to say I'm left confused Because trying to figure out how to measure the leg from IC7 over to OK3 becomes really confusing when I don't know what leg is what number

[mjr]

Looks like all my RGB's are working except this pesky 4G. I'm not sure if it is my cheap multimeter or not, but I'm not getting the readings I'm expecting. When I set it to continuity my multimeter doesn't have the feature to actually make a sound, it just switches from a 1 to a 001 when I touch the two leads together. When I clip one lead to the  JP11 Pin 5 and then start touching the other leads to the legs on IC7 I get several that register.To be honest I don't know which leg is leg 1. With the notch in the chip, does Pin 1 start to the left of the notch and then criss cross? If that is the case then leg 7, 8, 9 and 10 register 569 while legs 11 register 1198 and leg 15 registers a 002.

Needless to say I'm left confused Because trying to figure out how to measure the leg from IC7 over to OK3 becomes really confusing when I don't know what leg is what number

 

Here's a diagram that will hopefully help.  Pin numbering on all of these chips (and I think all chips in general) goes counter-clockwise around the chip starting with pin 1 at the lower left.  That still leaves the question of what's the "lower left".  To identify that, there are two main ways they mark the proper orientation:

 

- A "half moon" notch, like in the top illustration below.  This will be on the left side of the chip when properly oriented, viewing it from the top.  The notch sometimes goes all the way through the chip, but usually it's just a shallow depression 1mm deep or so, so you might have to look closely to find it.

 

- A little white inked circle, like in bottom illustration, or just a little shallow circular depression of the roughly the size illustrated.  This will usually be close to one corner, which is where pin 1 is.  Sometimes it'll be in the middle of one edge like the half moon notch, in which case it means the same thing as the notch - "this is the left side of the chip".

 

 

Once you identify pin 1, the pins are numbered 1, 2, 3,... left to right across the bottom of the chip, then continuing counter-clockwise right to left across the top.  

 

The circular numbering means that the highest numbered pin is directly across from pin 1 at upper left.  E.g., for a 16-pin chip, pin 16 is the one at upper left.

[roar]

 

Looks like all my RGB's are working except this pesky 4G. I'm not sure if it is my cheap multimeter or not, but I'm not getting the readings I'm expecting. When I set it to continuity my multimeter doesn't have the feature to actually make a sound, it just switches from a 1 to a 001 when I touch the two leads together. When I clip one lead to the  JP11 Pin 5 and then start touching the other leads to the legs on IC7 I get several that register.To be honest I don't know which leg is leg 1. With the notch in the chip, does Pin 1 start to the left of the notch and then criss cross? If that is the case then leg 7, 8, 9 and 10 register 569 while legs 11 register 1198 and leg 15 registers a 002.

Needless to say I'm left confused Because trying to figure out how to measure the leg from IC7 over to OK3 becomes really confusing when I don't know what leg is what number

 

Here's a diagram that will hopefully help.  Pin numbering on all of these chips (and I think all chips in general) goes counter-clockwise around the chip starting with pin 1 at the lower left.  That still leaves the question of what's the "lower left".  To identify that, there are two main ways they mark the proper orientation:

 

- A "half moon" notch, like in the top illustration below.  This will be on the left side of the chip when properly oriented, viewing it from the top.  The notch sometimes goes all the way through the chip, but usually it's just a shallow depression 1mm deep or so, so you might have to look closely to find it.

 

- A little white inked circle, like in bottom illustration, or just a little shallow circular depression of the roughly the size illustrated.  This will usually be close to one corner, which is where pin 1 is.  Sometimes it'll be in the middle of one edge like the half moon notch, in which case it means the same thing as the notch - "this is the left side of the chip".

 

 

Once you identify pin 1, the pins are numbered 1, 2, 3,... left to right across the bottom of the chip, then continuing counter-clockwise right to left across the top.  

 

The circular numbering means that the highest numbered pin is directly across from pin 1 at upper left.  E.g., for a 16-pin chip, pin 16 is the one at upper left.

 

 

Got it... sounds like the JP11 pin 5 to to IC7 pin 9 is registering correctly. I'll need to check the other chips later and then move on to the powered tests by the look of it. Is it alright that I am getting other readings on the other pins?

[NobodyYouKnow]

 

 

Okay, I'll try to get them both [the design files for the sensor mounting bracket and the connector board] uploaded soon.

 

Done!  They're both available via the Pinscape resources page:

 

http://mjrnet.org/pinscape/index.html

 

 

Thank you very much. The board is already ordered. 

 

Plunger bracket is a bit more difficult. Seems Shapeways does not accept native SketchUp files. So I'd either have to find another printer or try to convert the file. Unfortunately I'm a total noob when it comes to 3D printing. Any tips are appreciated.

 

Pete

 

 

Here is the plunger bracket 3D model in DAE format. I checked the pricing on ShapeWays. Either I goofed something up, or their pricing is prohibitively expensive. $70 is just a little rich. While I like the idea of a nifty little bracket, I think I'll continue on my current arc and fabricate one instead.

 

Of course, if someone out there has a nice 3D printer and wants to help a few folks out . . .

Attached Files

•  plunger_CCD_sensor_bracket_Pinscape_Mod_v2.zip   44.65KB   18 downloads

Edited by NobodyYouKnow, 01 September 2016 - 10:34 PM.

[Pete248]

Yes, would say it is ways overpriced. I suggest you ask on the forum, whether someone in your country could print it and send it to you. Got mine printed by a forum member from a German pinball forum. Paid twice as much as he was asking and still could have got 4 for the price ShapeWays is asking for one.

Edited by Pete248, 12 September 2016 - 08:30 PM.

[NobodyYouKnow]

Hey Mike. Long time, no see. Sorry to have been distracted from my Pinscape project. Sometimes "Life" just intervenes and changes priorities. Anyway, I am back on task to build my virtual pinball machine and need assistance.

I am working toward the goal of using DOF3 to interact with Pinscape. Thus far, I have completed my build of the Pinscape controller board and one each of the MOSFET and Chime boards. I have bench tested them, worked through a couple of construction bugs and have them working perfectly, using "DirectOutputTest.exe" 1.0.0.0 (with either device 8 or device 58) to probe the outputs, and the inbuilt Windows 10 joystick control panel to monitor button presses.

 

Here is working output from DirectOutputTest:

 

C:\Users\Pat\Documents\PinScape\DirectOutput5818_Patch_20160613>DirectOutputTest.exe
LedWiz units detected:
  LedWiz unit 8: LedWiz 08, 0 outputs
Pinscape units detected:
  Pinscape unit 8: Pinscape Controller 08, 73 outputs

LedWiz Equivalent Units:
  LedWiz 08 Equivalent, unit 8
  Pinscape Controller 08 Equivalent, unit 58
 

I have now turned my attention to using the board set as I/O for a mockup of my virtual pin cabinet. I am able to interact correctly with the "Small LED / Opto" outputs on the expansion board using ports 17-32. I am having only limited success here. I am using stock Pinscape V1 firmware (w/ EXPANSION_BOARD, 0xFAFA/0x00F0), LEDBlinky "SimpleLEDTest.exe" 6.3.0.0 and "LEDBlinkyConfig.exe". With this configuration, I can reach out only to the 5+1 RGB outputs on JP8 (ports 24-32). The "SimpleLEDTest.exe" tool will properly turn on these same LEDs and operate as expected. This functionality relies on the LEDWiz emulation native in Pinscape. This is as far as I have succeeded.

If I move to Pinscape V2, everything starts to fail. "DirectOutputTest.exe" operates as expected for everything on ports 24-32 only, and the LEDBlinky tools will fail with an access error in "LEDWiz.DLL", and will refuse to interact with the Pinscape boards (I know this is not your product, but it does demonstrate where I am hung up).

What is a known working Pinscape V2 configuration to allow LEDWiz emulation mode to work with the LEDBlinky tools, and what are the limitations of that functionality (i.e. only the first 32 ports, etc)? My ultimate goal is to use DOF3 to go beyond the limitations of LEDBlinky, once I understand how to work seamlessly with LEDBlinky.

 

Thanks again for all you do in this community.

Pat
 

[mjr]

Hey Mike. Long time, no see. Sorry to have been distracted from my Pinscape project. Sometimes "Life" just intervenes and changes priorities. Anyway, I am back on task to build my virtual pinball machine and need assistance.

 

I know what you mean about other priorities getting in the way of pinball projects.  Glad you're able to get back to what really matters!

 

 

If I move to Pinscape V2 ...  the LEDBlinky tools will fail with an access error in "LEDWiz.DLL", and will refuse to interact with the Pinscape boards (I know this is not your product, but it does demonstrate where I am hung up).

 

That is indeed a problem with the stock LEDWIZ.DLL.  The problem is that the Pinscape V2 software creates two Windows USB entries when you have the keyboard features enabled - one for the traditional joystick inputs and a separate one for the key inputs.  The stock LEDWIZ.DLL has a hard-coded assumption that there's only one interface per device, and it mangles its internal memory and crashes if this is violated.  

 

Fortunately, there's a solution.  There's an open source LED project for Arduino called lwcloneu2, and as part of that, they wrote their own from-scratch LEDWIZ.DLL replacement.  Their version is compatible with the original and is superior in many ways, among them the fact that it doesn't crash when running with Pinscape V2.  So you just need to replace your existing stock LEDWIZ.DLL with the lwcloneu2 equivalent.  I've actually been in the process just today of putting together a download page with that plus my merged Grand Unified DOF R3 (which includes the latest Pinscape updates plus all of SwissLizard's final code with full addressable LED strip support).  I just got the merged DOF working, thanks to Scottacus who's been testing it with his cool addressable LED setup.   Give me a day or two and I should be able to get all of that posted.  That should fix the LedBlinky crash and get you moving again.

 

 

What is a known working Pinscape V2 configuration to allow LEDWiz emulation mode to work with the LEDBlinky tools, and what are the limitations of that functionality (i.e. only the first 32 ports, etc)? 

 

The 32-port limit is in fact the key limit of LedBlinky and anything else that goes through the LEDWIZ.DLL interface.  The LedWiz has a hard-coded set of 32 ports, and this fixed count is embedded in the protocol it uses to communicate across the USB wire.  So it's impossible for anything that thinks it's talking to an LedWiz to address ports beyond the first 32.  The LedWiz protocol also is limited to 49 brightness levels, whereas the Pinscape board and DOF can use 256 levels, so you get somewhat smoother fades and better RGB color mixing.  But that's a much less important difference than the fact that you can only address a subset of the ports.

Edited by mjr, 19 October 2016 - 04:48 AM.

[mjr]

The new "Grand Unified DOF R3+" and LEDWIZ.DLL files are now available:

 

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

 

These updates should fix the problems with LEDWIZ.DLL crashing when the keyboard features are enabled.  The DOF update incorporates all of my latest Pinscape updates plus all of the base code updates from the November 30, 2015 official release.  It also eliminates the need for LEDWIZ.DLL entirely in DOF.  DOF now talks to the LedWiz directly via the USB connection.

 

The new LEDWIZ.DLL update is only needed if you want to use non-DOF software, like LedBlinky, Future Pinball, etc.  This new DLL is just a build of the LWCloneU2 version of LEDWIZ.DLL, which is a fully compatible open-source implementation of the interface.  That's only part of LWCloneU2 - the overall project is a compete LedWiz clone for Arduinos all as nice open source software.  Their version of the DLL has some big advantages over the stock version of the DLL - it's open source, it doesn't crash with Pinscape v2, and it has some nice threading improvements that should make it run faster for legacy software like Future Pinball.  Even people who don't use Pinscape might want to try it out if they're using Future Pinball, because it does non-blocking writes to USB thanks to the threading architecture - this might help if you ever encounter stutter when using FP with feedback devices.

Edited by mjr, 19 October 2016 - 09:22 PM.

[NobodyYouKnow]

Ahhh. Thank you, Mike. I had almost forgotten what progress felt like. Your "Grand Unified DOF R3+" is the bomb. LEDBlinky is now in the bag using the open-sourced "LEDWiz.dll", and DOF3 is coming along nicely. For now, I am using the ".ini" files straight from the ConfigTool. I will eventually dig a layer deeper and create my own ".xml" files, but one step at a time.

 

I am enjoying your V2 configuration tool. It makes setting up the Pinscape board really easy, plus it shows in detail which port is configured for what. I like that. I find the tool creates it's "Downloads" folder directly in my "Documents" folder, and I would like to have it under my "Documents\Pinscape" folder instead. It looks like the HTML code invokes a function in the binary ("window.external.ShowDocsFolder"), and I have not yet made the time to dig deeper. Can this be configured somewhere?

 

Tools like LEDWiz and LEDBlinky can support multiple LEDWiz boards. The LEDWiz emulation native in Pinscape plays nicely with this architecture for the first LEDWiz controller. I expect that if I added a second and third Pinscape board, that I could map these to the 2nd and 3rd LEDWiz boards. As an alternative, I wonder if it is possible to add new composite USB devices in the Pinscape code to emulate multiple LEDWiz devices in a single Pinscape board. For example, Pinscape ports 1-32 would also appear on virtual LEDWiz device 1, ports 33-64 would appear on virtual LEDWiz device 2, and so on. Sorry - I do not know much about the nuances of the LEDWiz and Pinscape implementations. I expect there are some very good reasons why you have not done exactly this. Please do not take this as a feature request - rather it is just some mental ruminations on my part. Maybe it is time for me to dust off some dated coding skills and see if I can contribute a little more directly to this project.

 

-Pat

[mjr]

Ahhh. Thank you, Mike. I had almost forgotten what progress felt like. Your "Grand Unified DOF R3+" is the bomb. LEDBlinky is now in the bag using the open-sourced "LEDWiz.dll", and DOF3 is coming along nicely.

 

That's great!

 

 

Tools like LEDWiz and LEDBlinky can support multiple LEDWiz boards. The LEDWiz emulation native in Pinscape plays nicely with this architecture for the first LEDWiz controller. I expect that if I added a second and third Pinscape board, that I could map these to the 2nd and 3rd LEDWiz boards. 

 

Yep, that should definitely work for any tool that can talk to multiple LedWiz units.  As I'm sure you've noticed in the config tool, you can set each Pinscape board to use whatever LedWiz unit number you want, so it's just a matter of setting up the client program (e.g., LedBlinky) to talk to the different units.

 

 

As an alternative, I wonder if it is possible to add new composite USB devices in the Pinscape code to emulate multiple LEDWiz devices in a single Pinscape board. For example, Pinscape ports 1-32 would also appear on virtual LEDWiz device 1, ports 33-64 would appear on virtual LEDWiz device 2, and so on.

 

I think that's a really good idea - it would be a nice way to extend full compatibility to practically everythying.  I've even thought about this a bit already.  There's good news and bad news about it.  

 

First the bad news: I'm pretty sure it's impossible at the USB device level with the KL25Z.  It's tantalizingly close to being possible, because Windows has all sorts of provisions for letting one physical device pretend to be multiple logical devices.  But unfortunately, not in the specific way for this one special case.  The way the LedWiz protocol is defined, each unit requires its own unique (within the system) USB Product ID code.  This is how the client identifies the different units.  The KL25Z does allow firmware to set whatever product ID it wants - which makes the LedWiz emulation possible in the first place.  But you can only have one product ID at a time on this device.  Unfortunately, this isn't just a software limitation; it's embedded in the KL25Z hardware.  As far as I can tell there's simply no way around it; they just didn't envision that you might want to pretend to be two physical devices at the same time, so they didn't make any allowance for it in the hardware design.  It might be possible with other microcontrollers, but it seems to be an immutable feature of the KL25Z.

 

Now the good news.  If we change our thinking just a little, I think it becomes quite doable.  Rather than having the KL25Z itself pretend to be mulitiple USB devices, I think we can have the open source LEDWIZ.DLL replacement pretend that it found multiple LedWiz units for each Pinscape unit it detects:

 

1. When scanning devices, check each one to see if it's a Pinscape unit

2. If so, ask it how many ports it has

3. Internally create additional virtual LedWiz units representing each block of 32 ports beyond the first 32

4. Report these additional virtual units to the client as extra LedWiz unit numbers.  For example, if you have a Pinscape board that's set to LedWiz unit #3 with 96 outputs attached, the LEDWIZ.DLL library would create three virtual units internally, with unit numbers #3, #4, and #5, each representing 32 of the outputs.  LEDWIZ.DLL would report to the client program (such as LedBlinky) that LedWiz units #3, #4, and #5 are present.

5. When the caller sends commands to the virtual units, LEDWIZ.DLL translates them into the appropriate Pinscape extended protocol commands to address the additional ports.

 

So the idea is that LEDWIZ.DLL knows how many physical devices there are, but it creates the illusion for client programs that each Pinscape unit is actually several LedWiz units.  Programs like LedBlinky would be none the wiser - they'd think they were talking to ordinary LedWiz units.  So anything that knows how to talk to multiiple LedWiz units could take advantage of all of the ports on a Pinscape unit without having to even know they're Pinscape ports.

 

 

Maybe it is time for me to dust off some dated coding skills and see if I can contribute a little more directly to this project.

 

If you want to take a shot at that, I'd be all for it!  The LWCloneU2 source code is all on GitHub, and it's actually pretty decent code (unlike a lot of open source!), so if you know your way around C++, it might be an approachable project.  The nice part is that all of the nasty low-level Windows API infrastructure is already fully in place (the DLL wiring and the USB interfacing).  There actually would have to be a little additional USB API code added to detect the Pinscape units, but I can point you to the code I used in DOF to do that, and it would look almost exactly the same in C++.  But otherwise I think it would mostly be a matter of extending the data structures to add this new type of virtual interface, and adding the Pinscape protocol formatting in place of the LedWiz protocol in the appropriate places.

 

I just added this to my to-do list, so if you don't beat me to it, hopefully I'll be able to work on it myself at some point.  I'm going to give you a good head start, though, since I still have a lot of documentation to write and other things to attend to first.

[twistedsistem]

Mjr - kind sir

Do you have any pcb's left you would like to offload?

Also do you have a YouTube channel showing off your cabinet? I would like to send to my friend so he gets an idea of this project


Thanks!!

Twistedsistem


Sent from my iPhone using Tapatalk

[mjr]

Do you have any pcb's left you would like to offload?

 

I do still have a few of each left.  PM me and let me know what you need.

 

 

Also do you have a YouTube channel showing off your cabinet? I would like to send to my friend so he gets an idea of this project

 

I haven't made a video that demos the whole cab, but here's a little glimpse, at least:  

[NobodyYouKnow]

Hey Mike. I have been using your awesome V2 Pinscape configuration tool. I wish I had that kind of configuration detail when I was bench testing my Pinscape board set. I love being able to visualize port numbers to the various boards. That rocks.

 

I am messing around a bit with the "Pinscape After Dark" mode, trying to map the button and LED to the "Extender" pins. Thus far, I have assigned the momentary button to #25, which is mapped to JP12-1. The LED is assigned to output #74, which is mapped to JP12-2, active low. Everything looks pretty nominal in the Pinscape Setup tool, but I am experiencing limited success.

 

I was hoping to see the #25 button appear as joystick switch #25, but I see nothing happening when I monitor switch closures in the Joystick control panel. Interestingly, if I assign the "Mute" keypress to #25, I do see PC mute toggling. My success with the LED is abysmal - I cannot get the LED to illuminate at all (I am using the DirectOutputTest tool for this part).

 

Suggestions? (Yes, I am resisting the urge to start code bashing . . .)

 

:hmmm:

[mjr]

I am messing around a bit with the "Pinscape After Dark" mode, trying to map the button and LED to the "Extender" pins. Thus far, I have assigned the momentary button to #25, which is mapped to JP12-1. The LED is assigned to output #74, which is mapped to JP12-2, active low. Everything looks pretty nominal in the Pinscape Setup tool, but I am experiencing limited success.

 

I was hoping to see the #25 button appear as joystick switch #25, but I see nothing happening when I monitor switch closures in the Joystick control panel. Interestingly, if I assign the "Mute" keypress to #25, I do see PC mute toggling. My success with the LED is abysmal - I cannot get the LED to illuminate at all (I am using the DirectOutputTest tool for this part).

 

You actually won't see any action in the joystick buttons for the night mode switch, since that's a purely internal function that doesn't send anything to the PC.  

 

If you've set the port to active low, you should wire the LED like this:

 

+5V -> resistor (1K) ->  (+)LED(-)  ->  JP12-2

 

The 1K resistor will be about right for most small LEDs, but it would be better if you used an LED calculator to get the exact size to use for your particular LED.  Plug in 5V for the supply voltage, use the "forward voltage" from the spec sheet for your LED, and use 4mA for the current, NOT the LED's spec sheet current.  The LED will probably say it wants 20 mA if you're using a typical small LED, but the KL25Z GPIO ports have extremely limited power handling - only 4mA max.  Most small LEDs will still light up with that little current, although they won't be as bright as at 20mA.

 

If that doesn't help, I'd try this.  Switch the port to active high in the config tool.  Get out your volt meter and connect + to JP12-2 and - to one of the ground pins.  It should be reading close to zero.  Use the DOF tester tool to turn the port on.  It should go to about +3.3V.  If that's working, you're good at the software level, so it must be something with the LED wiring.  If you don't see the voltage change, there must be some software or config problem.

 

One more suggestion:  If you have a spare output on the "flipper button/small LED" group that you're not using for something else, that would be easier to use as the indicator LED, since those will operate at higher current levels.  In that case, you should be able to run the LED at the full 20mA.

Edited by mjr, 01 November 2016 - 02:39 AM.

[NobodyYouKnow]

Well, Mike. As usual you are spot on. I didn't stop to consider the available 4ma drive current on the future-proof pins. In the end, I came around to what you advised, but not until after I found the spot in the KL25Z where they hide the "magic blue smoke" that makes everything electronic work. Well, I managed to let a lot of the smoke out, and now have a smashing new digital paperweight. By chance I did have a spare, so after bit of soldering and re-configuring, I have the spare up and running. Thank heavens I recognize my own proclivity to recklessness and socketed everything.

 

I am about done with benching, and am drilling holes in a cardboard mockup (a.k.a cardboard box) to work through what buttons I would like where. I have DOF sufficiently understood to begin making intelligent decisions there. At this point I have exercised every output on all three boards and am pleased with the results. I am having a bit of trouble getting the chimes to work. I can trigger each of the 8 timer channels with DirectOutputTest, and they function as expected. I am yet to figure out how to make the connection from pinball table to B2S to DOF to the chimes. I expect there is some lightweight script editing to do to enable them, but thus far it escapes me. I can trigger the flashers, solenoids, and low power LEDs from the table, so I know I am close. I would appreciate any advice here.

 

Would you be willing to share your DOF config files and scripts for a couple of your favorite tables? I say scripts only because some tables have embedded objects that make them far too large to post here. A working example, with all the bells and whistles (and chimes, of course) would be awesome.

 

I am starting to browse some of the DOF-related code, and am beginning to get a feeble understanding of what all the pieces are and how they work. Thanks for the nudges to keep me on the path.

 

-Pat

[mjr]

 I didn't stop to consider the available 4ma drive current on the future-proof pins. In the end, I came around to what you advised, but not until after I found the spot in the KL25Z where they hide the "magic blue smoke" that makes everything electronic work. Well, I managed to let a lot of the smoke out, and now have a smashing new digital paperweight. By chance I did have a spare, so after bit of soldering and re-configuring, I have the spare up and running. Thank heavens I recognize my own proclivity to recklessness and socketed everything.

 

Aw, sorry to hear about the blue smoke!  I'm glad you were able to get back in business with the spare, at least.  Socketing is definitely a great way to go.

 

 

I am about done with benching, and am drilling holes in a cardboard mockup (a.k.a cardboard box) to work through what buttons I would like where. I have DOF sufficiently understood to begin making intelligent decisions there. At this point I have exercised every output on all three boards and am pleased with the results. I am having a bit of trouble getting the chimes to work. I can trigger each of the 8 timer channels with DirectOutputTest, and they function as expected. I am yet to figure out how to make the connection from pinball table to B2S to DOF to the chimes. I expect there is some lightweight script editing to do to enable them, but thus far it escapes me. I can trigger the flashers, solenoids, and low power LEDs from the table, so I know I am close. I would appreciate any advice here.

 

I actually don't have my own chime box installed yet, so I haven't gotten to the DOF chime effects myself.  But if you go to port assignments page, there are entries in the drop-down list for each port for "Chime 1", "Chime 2", ... "Chime 5".  They're near the very bottom of the list.  So the first step, if you haven't already done this, is to make sure you have your physical chime ports mapped to chimes in the DOF tool.

 

The second step is to make sure you're running a table that actually uses chimes.  You can get a list of tables mapped in the DOF config by going to the Stats tab at the top and selecting "Chime 1" in the drop list.  That'll give you a list of tables that have DOF mappings.

 

The third step is to see if the table actually uses those!  Chimes are almost exclusively used in older EM tables, and the VP9 versions of most EM tables lack any DOF effects at all.  Your best bet is probably to pick one of the newer VPX EM tables.  Let's see... try this one:  

 

http://www.vpforums....&showfile=12411 (Triple Strike VPX 4.1.2)

 

That looks like it's set up for DOF chimes.  Now you just have to go your Visual Pinball\User\Controller.txt file and make sure the line with "UseDOFChimes" has the value 1 at the end:

 

UseDOFChimes=1

 

When you run the table, DOF should fire the ports mapped to Chime 1, Chime 2, and Chime 3 on various scoring events.

[NobodyYouKnow]

Wow! Something just clicked. I am starting to understand this DOF business. This gives me a bit more confidence that most of the pieces are placed and configured correctly. Thanks for the "Triple Strike" suggestion. That was key. For a greenhorn, there are lots of layers that all need to work together, and there is a certain amount of fiddly detail. These conspire to make most of what goes on confusing for me.

 

As an exercise in understanding, I have been converting one of the VP9 versions of this table to use DOF and feedback devices. I am a l-o-n-g ways from writing VBS scripts, but I can understand most of what I am seeing. My years spent as a script-kiddie are serving me well here.

 

Now I need to figure what is keeping VP8 from working. I expect it will be fairly obvious once I find it. I am trying to maintain single installations of B2S and DOF3. I also have a single Scripts folder that is working most of the time. It is probably something as simple as the inability to follow a shortcut that is biting me. Even VPX 10.2 fails if it finds links instead of actual directories, but at least it fails with meaningful error messages.

 

Thanks again, Mike, for speaking to me slowly and using short words.

 

-Pat

Edited by NobodyYouKnow, 05 November 2016 - 02:03 PM.

[NobodyYouKnow]

Sorry for the duplicate posting. I wansn't watching and put this question in the old thread instead. Please ignore that other post.

Hey Mike. I've created a 10x10 cm fan-out board in the same footprint as Pinscape to make distributing connections out to the various switches and LEDs a little easier. What PCB foundry did you use for the batch of boards you produced? I've been doing a bit of research, and there are tons of options out there. Some of them have better feedback than others. I'm more than satisfied with the quality of your boards, so I figure that is a safe way to go.

Once I prove the design works, I'll post the board and BOM here.

Thanks.

-Pat

[mjr]

Sorry for the duplicate posting. I wansn't watching and put this question in the old thread instead. Please ignore that other post.

Hey Mike. I've created a 10x10 cm fan-out board in the same footprint as Pinscape to make distributing connections out to the various switches and LEDs a little easier. What PCB foundry did you use for the batch of boards you produced? I've been doing a bit of research, and there are tons of options out there. Some of them have better feedback than others. I'm more than satisfied with the quality of your boards, so I figure that is a safe way to go.

Once I prove the design works, I'll post the board and BOM here.

 

I used elecrow.com.  I've done two batches with them so far and they both turned out well.  That's a small sample size compared to all the reviews on pcbshopper.com, but they get pretty good overall reviews there too.

 

This isn't applicable to this particular case, but just for future reference: For tiny boards, I've also used oshpark.com, and they do a great job.  Their board quality is top notch.  They're great for prototyping because their default order size is only 3 copies, and they're in the US for faster shipping (for those of us in the US, anyway).  But they're quite expensive for larger boards like these.  They charge by the square inch, so they're cheap if you have a little special-purpose board that you can pack into a square inch or two, but it gets prohibitive for big boards like you're talking about.

[NobodyYouKnow]

Thanks. That is great info. I was leaning toward Elecrow as the most likely min-tech provider. This cliches it. Are there any other production parameters you feel relevant? I'm thinking I'll go with 2 oz copper, solder mask top and bottom, silk screen on top. I'll need to review my design and confirm trace widths and vias are sufficient for the expected current. I don't have anything with close spacing, so I don't think there will be any issues there.

In case you have not already guessed, I have not done this before (aside from the canned order of the optical plunger board from Oshpark :-) ). What else am I missing?

Edited by NobodyYouKnow, 26 November 2016 - 12:27 AM.