Internet PLC Forum

Lately we've been having a lot of problems with the communications between our HMI software and the T100MD888+ PLCs in our machine.  We started logging the comms using Hyperterminal and a split cable and noticed a strange pattern.  It seemed the response from the PLC was corrupted but it was always the same character of the response.  For example, here are some of the corrupted responses:

@01Wb?4*
@01RD00003?001F001F001F001F001F001F001F001F0000000002B82B*

The "?" is what Hyperterminal prints in place of an unprintable ASCII code I think.  These errors have been captured multiple times and the "?" always appears in the same location for those errors (there are others).  This tells me it's not random glitches or RS232 noise.

Has anyone seen this pattern before?  I'm at a loss as to what could be causing it.

Thanks.  That Optrex doc looks familiar.  I must have looked into this before and managed to forget.

But yeah, I agree.  This doesn't look possible (or at least too difficult to implement).

Has anyone tried using T100 PLCs in an 12V automobile environment?  I know the PLC can be run at 12V but I wasn't sure if there are other concerns in this situation (engine noise?).

I got someone excited about the possibility of using a TriPLC combined with a touchscreen to control some systems on his custom car project and I want to make sure I'm not leading him down the wrong path.

I could be mistaken but I think you can have multiple versions of the JRE installed on the same machine.  At least they each have their own subfolder under "C:\Program Files\Java" and a quick Google search seemed to imply this was possible.

However you'd probably have to change how Trilogi is started up since .jar files will most likely be associated with the latest version of Java.  I think you could edit the shortcuts to point to the correct java.exe version and add "TL53.jar" (or whatever) as a parameter.

(I put "failure" in quotes because the PLCs are still working as far as I can tell.)

We fried the resistor located next to the COMM1 port on two T100MD888+ PLCs recently (both part of the same machine).  I had done this once before on a 1616+ PLC and when I emailed Triangle back then about this resistor I got the following response:

The large resistor next to COMM1 reader is a current limiting
resistor that connects the ground voltage of the PLC and that of the
PC (or other devices) being hooked up to COMM1. For some reason your
connection caused a ground fault on the system, meaning that the
PLC's ground could have been connected to a power source non-
isolated from the power supply of the PC. When the devices are
connected the ground potential difference between the PC and the PLC
cause a large current to flow through the resistor and cause it to
burn out. Usually you just need to replace the resistor and check
the power source to ensure some isolation.

In the most recent situation it appears the problem (as far as we can tell) was that someone put a lock washer under the mounting screws and one of them penetrated the solder mask and made contact with a trace.  I believe it is a ground trace -- it's the one nearest to the mounting hole next to U12, on the component side of the board.

So if I'm analyzing this correctly the PLC's ground was tied to the machine's earth through the screw (since our chassis is tied to earth). However, our machine uses power from a 208 outlet while the PC is plugged into a seperate 110 outlet.  So it seems there was a difference in ground potentials between the PC and the machine (a seperate matter we need to address).

Does this make sense?

You could use external relays.

Should it be possible to use a T100MD2424+ in place of a T100MD888+ without concern?  Judging from the specs on your site it appears the 2424+ is a superset of the 888+ with the only differences being the additional I/O, the use of terminals for analog I/O rather than D-sub (a good thing), and the addition of the MCR input.

Any hidden gotchas I should be aware of?  Maybe differences in available PWM frequencies or stepper frequencies?

I like the idea of variable names, too.  Currently I have to maintain seperate documents to track which variables are being used in a program to ensure I don't reuse them.

You wouldn't necessarily have to change how variables are monitored I think.  If you make it so you specifically assign names to memory locations, probably adding another page the I/O tables, you could still have the monitoring interface simply show things as they are now.  As long as the variable name tables are easily accessible (maybe listed on the initial debugging screen) then it wouldn't be that hard to know which variables to look at in the other monitoring screens.