25 replies to this topic

[doogie2301]

@doogie2301: Your screenshot is cut off after COM5. Is there anything else? The error after COM1 shouldn't be the problem if you're saying that your device sits on COM3. Does COM3 appear in the log anywhere at all?

 

No, it stops there, nothing happens after the COM5 line.

 

@doogie2301: Yes, that's because I also changed the PinDMDv3 implementation to a native one. Did Russell say why you needed to hard-code the COM-Port in your ini? I can probably add an option for that too, but it would be interesting to know why auto-detection doesn't work.

 

I don't know why this was needed.  At one point it was working without it, but then after updating pindmd and/or Windows 10, it no longer showed up in the device list.  Now it just shows as a generic usb serial device, so I used the ini file to get it to work.

[freezy]

Weird. Well, I can add a --port parameter to dmdext if that will help.

[doogie2301]

So COM5 is my Zebsboards PinCab Controller, after I unplugged it, it continued on to COM3 and found the pinDMD3.  Any reason why it might be hanging when it gets to the zebs device?  Anyway, I guess the order is different now after I plugged it back in, because after checking COM7 it goes to COM3 and finds it.  

 

Now next problem is, COM7 is my SainSmart relay board, and it seems when DMDExt checks on COM7, it activates two relays (2 & 7) and they remain on!  I used the same trick and disconnected and plugged back in to change the order for now, hopefully that will stick though and not reset at some point.

[freezy]

Haha yeah you have exactly the use case I hoped wouldn't happen. Basically I need a way to find out which COM port PinDMDv3 is plugged to. Since COM devices don't have IDs or labels or anything useful apart from the COM[number] name, the only way I got so far to identify PinDMDv3 is to actually query every port for the firmware string. You experienced the 2 cases where this could go wrong:

 

1. It does something it's not supposed to do on another device

2. It hangs for some reason because the other device doesn't send anything back

 

@russdx, how does pinDMD.dll do it? Somehow it fails too because doogie2301 had to specify the port explicitly in pindmd.ini?

Edited by freezy, 29 August 2016 - 09:33 PM.

[doogie2301]

Weird. Well, I can add a --port parameter to dmdext if that will help.

 

So I think I'm going to need this, if possible.  It seems the order of the COM ports does get reset, so I can't rely on COM3 being checked before the others.  Thanks.

[takut]

I really love the dmdext program and it works perfect on PFX2.

 

Then I try to run dmdext on for Pro Pinball Timeshock, but my PinTwoDMD shown only a dark device.

 

With the version dmdext-v1.2.4 PFX2 works perfect, but this version don't support Pro Pinball.

 

The version dmdext-v1.3.0-beta1 and with the version dmdext-v1.3.0-beta2 don't find the PinTwoDMD device (see attached screenshot).

 

All files are unblocked and the dmdext.exe run as administrator.

 

Any idea for a solution?

 

 

Attached Files

•  cmd.PNG   21.48KB   3 downloads