Sign in to follow this  
Followers 0
Syd

SLC Ch.0 ASCII READ

6 posts in this topic

I have project involving several RS485 weigh scale modules communicating to a SLC 5/05 processor. The application is up and working, however the ascii read (ARD) instruction does not seem to pick up the response characters properly from the scale unit. If the weigh scale units are told to delay 1/4 second before sending the response message back to the PLC everything works well. If I make the delay smaller, or remove it entirely, the PLC seems to miss the incoming message. Obviously with 9 scales at 1/4second delay each, this is unacceptable. Anyone seen this type of problem or have suggestions? The application has only one clear buffer instruction (clears both TX&RX). It is sent during the initialization before each write operation to poll the scales. Sydney

Share this post


Link to post
Share on other sites
If you can post your program or the section of the program that is doing the ASCII transactions that would help a lot. As I understand the SLC's Channel 0 buffers, they should be able to receive incoming data even at the same time as data is outgoing. There could be a problem in the way your code is written, or there might be something in the RS232/485 conversion that you are necessarily doing between the SLC and the RS485 devices. What kind of converter do you have ? Post whatever other information you have about your application and Forum members may be able to help more.

Share this post


Link to post
Share on other sites
To learn more about SLC ASCII instruction speed, I wrote a three-rung program that sends out the string "Hello World !". When my serial analyzer sees the word "Hello", it replies with "Hello". This means that the extra seven characters of the outgoing string are transmitted by the SLC at the same time as the incoming buffer is receiving the reply. I also used the SLC's free-running 10 millisecond clock to determine from the processor's perspective how long it takes between the sending of the outgoing string and the reception of the incoming string. The SLC clock values varied betwen 20 to 50 milliseconds. At 19200 bits per second, a character takes 1/ 1920th of a second to transmit across an RS-232 connection, so the string "Hello" takes only 2.6 milliseconds to be transmitted, and the same time to be replied to. So the rest of the time is SLC scantime and the time it takes for the SLC ASCII buffers to run. Still, this shows that the whole transaction is over in 50 milliseconds at the outside, more than 5 times faster than the threshold you're seeing. So your SLC is of course running a much larger program. Maybe the scantime of your controller is contributing, or your data strings are much larger, or your data rate is much lower. Post as much information as you can. Here's a screenshot of my serial analyzer output (attached). Also, the short test program (RSLogix 5000 v 8.0 format) BUFFRS.RSS

Share this post


Link to post
Share on other sites
Ken, thanks for the reply. Here is the test program. Today we found out that the analog input modules are somehow affecting the CPU...even one-shot rising logic failed to trigger. The rack has 2-8 channel AB analog inputs and 2-4 channel AB analog outputs in slots 1 through 4 respectively, along with a host of digital modules and an expansion rack on the SLC backplane cable. Removing both of the 8 channel analog cards caused the program to run okay. Adding one card back in caused the program to run slowly. Adding a single 4 channel input card was okay...adding a second 4 channel input card and program ran slowly. Adding one card in the main rack and a second in the slave rack also resulted in slow running program. Note that the test program has no logic for the analog cards, they are just declared in the I/O structure and sitting there. Yes, they will be required by the rest of the machine application. Any suggestions? Jon NEIL_WORKING_OCT02.RSS

Share this post


Link to post
Share on other sites
The addition of analog cards absolutely should not cause logic to malfunction or the controller to execute slowly. You may have a significant signal noise problem or defective hardware somewhere. You should investigate those aspects thoroughly with Tech Support before tackling this ASCII execution problem again.

Share this post


Link to post
Share on other sites
The delay introduced by some RS485 converters can get pretty nasty sometimes. It doesn't provide an answer related to the analog card problem but it might have something to do with the slow response in the communications.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0