NETCMD$ wait time

[cdenk]

The Trilogi manual indicates that NETCMD$ will wait a specifed time for a response. What is the time? is it settable?

If in the event of a FCS error, a serial error flag is set, how can I check it?

[cdenk]

Found the answers in the Trilogi book: The commands are SETSYSTEM and STATUS.

[support]

Yes, those are correct commands to do what you want to do. The default wait time is 0.15s for NETCMD$, READMODBUS and WRITEMODUS command. You can increase by a multiple of the wait time but it also increases the scan time of the program, so beware of how it could affect the program execution.

[cdenk]

While troubleshooting I am trying to use the online monitoring to show the netcmd# received string, I find with the wait time greater than .15 x 20 the Comm1 to the PC times out.

Have been having been problem with the RS-485. With PC connected through a RS-232/RS485 convertor that transfers data both directions fine. There is a PIC18 based embedded system that also has RS-232 (also has fiber optic for final install) that works fine connected to the PC, but when connected together the PLC apparently is putting out the command string either with NETCMD#  ,or  PRINT#, and the PIC doesn't respond. This is with both the command and response strings sent and received each way on the RS-232, but connect the 2 together, and no response. I feel that some of the problem is NETCMD$ timing out since the PIC is slow, with the overhead of processing the received/sent strings and 3 ADC conversions one after the other. The RS-485 is short at around 2' long, and at this moment has a 120 ohm terminating resistor across the +/- terminals at the PLC. Have tried other configurations also, both since communications to the PC are solid, I don't think that's the problem.

Any thoughts would be appreciated. :~  

[support]

So you are connecting the PLC's RS485 port to the PIC board's RS232 port? What kind of RS232 to RS485 converter are you using on the PIC side? Does it auto-turnaround like the Auto485 converter? If it doesn't auto-turnaround then you may need to program the PIC to control the RTS pin on the converter in order to control the direction of data flow on the RS485. Otherwise, get an Auto485 to solve your problem

 http://www.tri-plc.com/auto485.htm

[cdenk]

I have a B&B Electronics 485TBLED RS-232 to RS-485 Convertor http://bb-elec.com/bb-elec/literature/485TBLED-3803ds.pdf

It has a jumper for RTS control, straight through, or with auto-enable  with time out. I have selected the auto enable.
Actual speed is not important, even one character per second would work. Planning to program the PLC to ensure enough time between transmission and reply to ensure no data collision. The PIC is all straight inline code.

Since, with the PLC connected directly to the PC through the convertor data transmission is OK, I don't think the basic hardware is a problem, but maybe timing of the PLC and PIC being off slightly relatively.

It would be good if I could feed data in PLC comm3 either from anoother PC or the PIC and echo it out comm1 to the the other PC.

Using INCOMM 3 and OUTCOMM 3 about 10 characters @2400 baud can echoed from the PC to the PLC and back to the PLC. More than that and the data collides.

Have had some problems getting the DM = INCOMM 3 DATA into the DM[] memory though.

[support]

You may also want to check if the PIC embedded board RS232 is DTE or DCE configuration. Most likely it is opposite that of the PC and you therefore need a null modem cable (2-3,3-2,5-5) to crossover the signal when connecting the same converter to the PIC board.

Remember that the PLC has 256 bytes serial buffer, so you need not be monitoring one character at a time. You may want to check the comm port 3 every few seconds, then echo all the characters you received via INCOMM(3) and send out by OUTCOMM 1 until the buffer is empty. That way I am sure you can raise the throughput to well above 2400bps.