Host Engineering Forum
General Category => DirectSOFT => Topic started by: MichaelL65 on April 11, 2007, 03:43:52 PM
-
Have some questions regarding sending and receiving ASCII strings. I'm using a DL260 processor and a series of RS-485 devices that I want to talk to. I know what I need to send and what I should receive from the program point of view, but I'm not clear on the syntax of the instructions.
The process is this: I'm getting a digital input to tell me there is an error in one of the devices, and I need to poll it, get a status word back, and convert it to a hex number so I can look at the individual bits to see what the errors are. I only want to run these routines when there is an error, so I was thinking of putting them in subroutines that run only on the leading edge of the corresponding input going high.
First, after getting the input, I'm sending a string to the offending device using the PRINT box. This appears to be able to be a trigger once and it executes instruction. So far so good.
Next, I expect an answer back and use the AIN box to get it. Do I need to hold the input line to it high while that executes? Or is it like the PRINT box and I only need to trigger it once and it runs on it's own until it gets the data or times out?
The answer I get is going to be a series of numbers that AEX should be able to convert to a number. Again, do I have to hold the input high or just trigger it once?
Also, between each of these there needs to be a slight delay - but I'm also trying to run the subroutine only once. Is there a way to do that or do I need to keep running the subroutine until the sequence is complete?
This is the first time I've needed to use ASCII functions in a PLC program, and as luck would have it on my first project with the Automation Direct PLC (I'm used to Toshiba T-series). I know it can get there and a general idea how, but in switching platforms I'm finding a lot of gaps in my knowledge!
-
MichaelL65, sorry for the delay. We are not the experts on this question, but Automation Direct is. Actually we have a guy here that could probably answer you but he is out-of-pocket lately (thus the delay). If someone from Automation Direct doesn't answer you here, you might try posting on their forum (http://forum1.automationdirect.com) or giving them a call. Sorry :-\
-
I was starting to wonder if this was not the place to post the question, especially after I found the forum at AutomationDirect.com. I was not the first one there with similar questions - I found several with a quick search, and it was not good news. In case anyone else was watching this post for the answer, here it is as I understand it:
You can send ASCII data on port 2. You can receive ASCII data on port 2. They really did not intend for you to do both in the same program. As for the exact syntax, that was really irrelevant as I needed to send something and immediately read what was received back, and that is not something the 260 processor can do.
The recurring solution was to get the F2-CP128 BASIC co-processor and let it handle the data. Not ideal, but it will mean less re-wiring of the panel than any other solution I could come up with. :(
-
You can send and receive ascii in the same program. You just have to open a transmit window, send the ascii, close the transmit window, open a receive window and then wait for the ascii data to be received. I am using a polling method to send 3 different ascii values to a lasermicrometer, and receive the data back. Use interlocking so you can not have the transmit and receive windows open at the same time. I can get more in detail if you wish.
Robert
-
I did see some posts at AD's forums about doing that sort of thing with mixed results. Seemed that often there was a missed byte or two while the PLC switched unless the other device had the ability to delay the response, or unless you could use handshaking. The devices I'm talking to (Animatics SmartMotors) respond immediately and have no handshaking capability on their end, so I'm afraid that won't work.
I got the co-processor today. Programming interface is ugly as all get out, but they have sample code of doing almost exactly what I need. This project I'm going to go with it (especially since I talked my boss into getting one ;) ), but I would still like to see how you suggest doing it.
-
You need to go with the copro since you cannot delay your slave's response. :-\
Someday, it would be good to have true full duplex serial comm built in.
-
On the 250, 260, or 06 CPU you can set up the secondary serial port using Directsoft..PLC..Setup..Sec. Com Port.
Set the port for non-sequence and under address, put V6000 (or any place you have 64 words to spare).
Now when anything is sent to the port, it will store it at V6000. V6000 holds 81 and V6001 holds the data string length. Your received data starts at V6002.
Now use the PRINT command to build and send data out of the port. If the data triggers a response, it will be stored at V6002.
Now check to see if V6000 is not zero. If true, then process your data and clear V6000 to allow more data into your 'buffer'. You only need to clear V6000, not the entire buffer area.
This at least gives the appearance of full duplex, if not the real deal.
I hope that helps, Keith