Hi-
We are using several M340s in different applications. The M340 CPU has an RS232 / RS485 port. Square D has implemented the serial communications such that, when sending a string via RS485, the transmitted string is written the input buffer as data that is read. In programming, we have to strip out the transmitted command.
The purpose of the communications is pretty straightforward, or so we thought. We issue a "read data" request to an instruments using the print_char function.
The method of string termination depends upon exactly how the data is read into the PLC. If the mode is to stop on carriage return ( <CR> ), then the echo of the transmitted command is stripped off the input buffer using one input_char function, then the actual data is read using another input_char function. If the mode is to stop on silence, one input_char is executed, and the returned string is then parsed to extract the data.
The issue is this: whether using either method of reading the data (stop on <CR> or stop on silence), the PLC sometimes "misses" the device's data string - several times an hour based on reading the data at 100ms to 3 second intervals. We know that the device is actually sending the data because we see it in hyperterm - the device never fails to transmit the data. There are no other devices on the RS485 network at this time. This behavior has been seen with a variety of different devices.
Has anyone else seen this behavior? We've got the local distributor applications engineers working on it, but I didn't want to re-invent the wheel if we didn't have to. We also have a tech support case open with Square D, but so far they have been no help at all. The main advice given to us concerned the NOM communications, which we'd rather not go with if we don't have to (although the NOM seems to work fine).
We have run into a slew of other issues regarding the RS485 communications, such as issues with setting the maximum number of characters to read while the PLC is solving, attempting to clear the input buffer (it looks like it's impossible), and other issues that I can't remember. However, we've solved them except for this one issue.
thanks in advance.
We are using several M340s in different applications. The M340 CPU has an RS232 / RS485 port. Square D has implemented the serial communications such that, when sending a string via RS485, the transmitted string is written the input buffer as data that is read. In programming, we have to strip out the transmitted command.
The purpose of the communications is pretty straightforward, or so we thought. We issue a "read data" request to an instruments using the print_char function.
The method of string termination depends upon exactly how the data is read into the PLC. If the mode is to stop on carriage return ( <CR> ), then the echo of the transmitted command is stripped off the input buffer using one input_char function, then the actual data is read using another input_char function. If the mode is to stop on silence, one input_char is executed, and the returned string is then parsed to extract the data.
The issue is this: whether using either method of reading the data (stop on <CR> or stop on silence), the PLC sometimes "misses" the device's data string - several times an hour based on reading the data at 100ms to 3 second intervals. We know that the device is actually sending the data because we see it in hyperterm - the device never fails to transmit the data. There are no other devices on the RS485 network at this time. This behavior has been seen with a variety of different devices.
Has anyone else seen this behavior? We've got the local distributor applications engineers working on it, but I didn't want to re-invent the wheel if we didn't have to. We also have a tech support case open with Square D, but so far they have been no help at all. The main advice given to us concerned the NOM communications, which we'd rather not go with if we don't have to (although the NOM seems to work fine).
We have run into a slew of other issues regarding the RS485 communications, such as issues with setting the maximum number of characters to read while the PLC is solving, attempting to clear the input buffer (it looks like it's impossible), and other issues that I can't remember. However, we've solved them except for this one issue.
thanks in advance.
