NETCMD$ TIMING?

[cdenk]

What happens while NETCMD$ is waiting for a reply? Does the CUSTFUN containing NETCMD$ wait with the PLC stuck at that CUSTFUN? Or does it function more like an interrupt, with the PLC going through the ladder, and either when coming to that circuit picking up the new data, or actually interrupting the normal execution?

If the circuit containing the CUSTFUN has a 0.1s clock special bit contact, and NETCMD$ set for 3 tries (Setsystem 2,3) and Wait set for 0.15 x 50 = 7.5 seconds, will this result in overlap, where NETCMD$ is trying to send, and the remote unit also replying with possible data collision on the RS-485?

[support]

The standard wait time is 0.15s. NETCMD$ waits for the response from the slave. During this time the CPU does not execute any other ladder program (and therefore the custom functions controlled by the ladder program). The CPU will still respond to serial command and will handle interrupt based custom functions (interrupt, HSC) but the system essentially stop. So it is not recommended that you increase the wait time to such long delay.

If the slave respond very slowly, then you may consider sending out the command using PRINT, then use another custom function that runs the INPUT$() function to periodically check for the response. If nothing is received, continue the ladder logic execution and come back in the next scheduled time (using clock pulse to only check once every period) to check for response from the slave device. That will be the most efficient way of using the M-series PLC for this purpose.

[Fiddlerdave]

I see a difficulty for an application I am considering with the comm timing and overhead.

I wish to use TH100MD as a host, connecting to up to 15 E10+npn unis with the RS-485.  They will be polled regularly (it would be good if I could poll all 15 in a .5 second loop for simple I/O input states, with a very an occasional single on/off variable would be sent to the remote  E10 unit.

There will be an optic sensor input on each E10 (as well as on the MD unit) with input of as little as 15ms duration that I need the E10 to register and latch in memory to respond to the poll from the Host  to inform the Host an input pulse did occur, even if the pulse is gone.

Some E10 units will also have a motor position sensing digital I/O input (simple switch detector on a cam), that when activated, the E10 must turn off an local output within approximately 50 to 70ms of the input rise (programmed to be done locally, not through the host MD).

Is the NetCMD$ wait time of .15s a timeout?  Will successful, short (digital I/O monitoring or setting) message take less time?

Can an E10 unit latch (remember) an input occurance (not trying to count them,  more than one occurrance doesn't matter) while handling a Host communication request?  And can I ensure a local E10 output state be turned off in 50ms from a local  input rise in the E10 while it is polled regularly from the Host?

[support]

Yes, 0.15s is the time out. If the comm is successful then the response time from the E10+ is very short (about the same as the E10 scan time plus communication transmission time).

You can program the E10+ with local intelligence so that it can latch an input pulse or even count the number of incoming pulses. And locally the E10 can turn ON/OFF whatever output based on the logic  the program resolve when a particular input is ON. All these can be done without the intervention of the host T100MD+. 50ms is plenty of time for the E10 to turn OFF an output (it will likely to do it within < 5ms).

That's why the E10+ PLCs are really not just remote I/O, but "smart" remote I/Os since they can each be programmed to respond to local conditions quickly without intervention from the host. The host T100MD+or a PC can leisurely query the slave PLCs for status change etc.

[richard2511]

This post has someting to do with the thread:
I have a T100MX-4832 with an MDS 100 Display and two ICP I-7018 A/D Converters hooked to the T100MX COMM 3 port. Everyting goes nice and neat till I try to connect the whole jig to a PC through an Auto 485 converter ... Not just while the converter is connected to the 485 line but as soon as the converter gets plugged into the PC and nothing happening on the RS232 there, just the disabled port ! The T100MX becomes incredibly sloooow, monitoring with TL Server and TriLogi through COMM 1, even with another PC, also, besides MDS 100 display comes up showing some garbled, misplaced or unwanted texts. Data coming from the A/D's seems to be unaffected.
Forcing the RS232 on the PC into a known state and silencing any eventual transmission through the port doesn't change this behaviour. Poking around with the c++ thing I composed to do so and bringing the receiver to a text window showed a lot of garbage in between the display messages, but quite clean coming and going to the A/D's. Display and A/D routines are based on NETCMD$, A/D's are interrogated at a per second rate and display is updated 5 times slower. So ... question: what may be happening here ?
Another question: some code or library for native TriLogi protocol in C++ to be found somewhere ? I am trying to build a display and logger for the application with the setup described here. The application monitors 14 temperatures and controls heating and ventilating under time controlled conditions.
Best regards, and thank you for your support.

[support]

It appear that for some reasons your Auto485 is affecting the RS485 port. It could be either the RS485 driver on the Auto485 is damaged or there may be a ground fault between the PC and the PLC's power supply.

1) If you unplug the PC from the RS232 connector of the Auto485, does it still affect the communication?

2) If you pause the PLC (say by turning DIP switch #4), are you able to use TLServer and Auto485 to perform online monitoring with the PLC via COMM3? This will test whether the Auto485 is working.

3) If your PC is a laptop, could you try to run the laptop on battery without connecting to the AC? If this work then there is likely to be a severe ground fault between the PC and PLC's power supply.