the basic of ASCII programming in RSLogix

Greetings to everybody,

I must configure my PLC, an Allen Bradley 1769 LE32E, so that it can send sms via a modem Wavecom WMOD2 when any specific events might happen.

ASCII is a field of the programming absolutely new to me and though I've found quite a complete documentation from the AB resources web I still was wondering if any of the members in this forum could suggest me other additional documentation explaining the very basics of the ASCII programming. There are, for example, some terms like "buffer" in the AB literature which meaning I'm not sure to have yet completely understood.

Thanks in advance.

Buffwer is a group of registers that serves as a temporary storage area to compensate for rate differences between transmitter and reciever. I would also look at the SLC500 instruction set manual under chapter 10 "ascii instructions"

ASCII programming

Thank Mordred,

I'll try to come back here with more specific doubts on ASCII as soon as I finish to adapt a piece of code that I've just found for the SLC500 and I can post it.

when you say ascii, are you referring to using the serial RS232 port? or just generic ascii instructions?

yes, that's it...I'm meaning the serial port RS232. I'd like to understand better the basics of ASCII instructions related to the serial port.

ASCII serial port

Here I come back again trying to describe more specificlly my doubts. I've got a piece of code that other member here has sent me (thanks WidelTo) which himself got from the Rockwell Sample Code Library. I attach it with this post.

Following I'll try to explain my doubts in the "SendTextMessage" routine...


Rung0 :




The bit EnableACB: when is this bit meant to be set? when, for instance, an event happens (an alarm is triggered) and I want to notify this via sms?...Not sure of this, cause in the following rung there is another bit already called "SendText"

The ACB instruction is for checking whether there are characters in the input buffer. Easy to understand, but: what's for the following instruction MOV in this case?





Rung1 :




When "SendText" bool bit goes true, for one scan cycle, next events happen:

"SendTextState" variable gets the numerical value 1 ( for assigning/identifying a functional state to the process)

AND

SendTextCtrl.LEN is initialized to zero. This variable indicates the number of characters to be sent.

Doubt: Why does it must be initialized to 0?

AND

The AWT instruction writes the first part of the txt command in the serial port output.

SerialPortControlLenght = 23 , does this mean that that my SMS will be 23 characters long as much? I guess I can change this up to the maximum size number of characters allowed to be sent per one single SMS.



Rung2:



WHEN

SendTextState=1

AND

the AWT instruction from the rung above has sent the AT command and the phone number ( SendTextCtrl.DN =1)

THEN

Charsbuff is initialized to zero and the new state of the process is defined like SendTextState=2




Rung3:




As the rung comment says: "Step 2 - wait for at least 3 chars and read them - move to step 3"

What does exactly mean "wait for at least 3 chars"? Does it mean that the rest of the routine execution must be hold on until the output buffer used for the SMS sending read/counts up to 3 chars? so why this?...I don't get the reason to be for this rung.

Again the bit "EnableACB": why there again? what for?

So...When CharsInBuffer greater or equal than 3
we move the CharsInBuff to ReadPromptCtrl.LEN (variable which indicates how many elements must be moved to a certain destination variable) and by means of the ARD instruction those 3 chars are moved to the "TempStringx" (the destination variable)

Here comes my doubt of a very newbie programmer to ASCII : What's that '$r$l>' in the ARD instruction block?

When all this is done the SendTextState goes to 3.



Rung 4:



The rung 3 has been executed and ReadPromptCtrl.DN=1 and now we sent the SMS.

Doubt: Again, Why we initialize to zero the SendTextMessageCtrl.LEN ???

Other question in addition to the preceeding ones is next:

Taking a look to the rung4...how to write over the "SendTextMessage" STRING ? This is: what about if I want to send different SMS texts under different conditions? where and how I do this?

buhnen said:

Rung0 :




The bit EnableACB: when is this bit meant to be set? when, for instance, an event happens (an alarm is triggered) and I want to notify this via sms?...Not sure of this, cause in the following rung there is another bit already called "SendText"

The ACB instruction is for checking whether there are characters in the input buffer. Easy to understand, but: what's for the following instruction MOV in this case?

Click to expand...

EnableACB is set in rung3 as part of state 2. you dont have to worry about it. it looks like it is 'sendtext' that initiates the process.
why the MOV? probably because they want a snapshot of it when the ACB is not enabled. it probably changes when the ACB is working.

Doubt: Why does it must be initialized to 0?

Click to expand...

look in the help. this answers the rest of your questions for this rung.

If you want to set the Serial Port Control Length equal to the number of characters in the Source, enter 0

As the rung comment says: "Step 2 - wait for at least 3 chars and read them - move to step 3"

What does exactly mean "wait for at least 3 chars"? Does it mean that the rest of the routine execution must be hold on until the output buffer used for the SMS sending read/counts up to 3 chars? so why this?...I don't get the reason to be for this rung.

Click to expand...

I assume this is the response from the modem from the write in rung 1. it is waiting until there is at least 3 characters returned from the modem to reduce the chance of getting an imcomplete message.

Here comes my doubt of a very newbie programmer to ASCII : What's that '$r$l>' in the ARD instruction block?

Click to expand...

that is carriage return plus linefeed. it is what happens when you press 'enter' on your keyboard.

Doubt: Again, Why we initialize to zero the SendTextMessageCtrl.LEN ???

Click to expand...

see above.

GSM modem

Thank you very much Chris for your very detailed step-by-step answer. Moreover, with the help of this pdf --> 1756-pm013_-en-p "ASCII strings programming "from the official Rockwell library, I've got to fully understand the program.

As soon as possible, when I get my GSM modem, I'll start testing the code.

Hi again!

The D-day has arrived...I've got my gsm Wavecom modems ready for running and testing my sms-sending code along with them.

I've got to communicate successfully the Wavecom modem with the Hyperterminal microsoft software for activating the SIM cards and set some parameters through the AT command line programmation...

BUT...

when trying to test the above posted routine for the sms sending I'm not getting any result...

Does anybody of you know how to check whether the communication between the CompactLogix serial port and the modem is set up right ? I guess this can be done via the RSLinx but don't know how...I mean, keeping connected the CPU and the modem via RS232 and my laptop with the CPU via ethernet.

There's a led on the CPU faceplate called ch0, I guess meaning the Channel 0 , but I haven't ever seen it turned to green when both devices are linked...and there's also another led called DCH0....The AB documentation doesn't explain too much about these leds, so it's not been of a great assistance to me.

What I should firstly try to find out is whether the devices are communicating ok, putting off to further along the issue concerning the code itself (if it works or not)

In the Controller Properties, under the Serial Port tab, I've ticked and set the following options:

Mode:user
Baud rate: 9600 (as my modem is also set to this speed)
Data Bits:8
Parity: None
Stop Bits: 1
Control Line: Full Duplex

...and under the User Protocol tab :

Protocol: ASCII

Read/Write Buffer Size: 320 (by default this parameter gets the value of 82, but I read that it should be set to a value twice the number of characters allowed to send per sms)

I haven't modified any of the rest parameters within this tab


I hope you can help me out with this...
and thanks again.

i think the ch0 light should come on when the modem is attached, but i cannot quite remember. The configuration you have mentioned should be right.

Are you getting any action with your program when it is attached? Is your buffer query instruction getting any responses?

zankorel said:

i think the ch0 light should come on when the modem is attached, but i cannot quite remember. The configuration you have mentioned should be right.

Are you getting any action with your program when it is attached? Is your buffer query instruction getting any responses?

Click to expand...

Problem apparently solved....at least I've got to troubleshoot the issue concerning the pairing via serial port for both the modem and the PLC.

Coincidentally, I've noticed the DCH0 Led was fading to grey everytime I changed the default transmission speed of 19200 to other lower values such as 9600. I haven't though, yet checked more thoroughly whether I get the same trouble for all the rest of speeds.

Other issue: As I could read to any configuration manuals, the mode option, under the Serial Port tab, should be set to "user". I haven't got results this way (again the DCH0 led was going off) so I've had to choose " System" instead...and it worked

So after having tweaked these couple of settings, I've finally been able to send a test sms to my mobile....Now I'll keep checking around other things regarding the routine code.


...and forgot to mention: I've chosen "Non Handshaking" in the Control Line instead of "Full Duplex"

I've succeeded with sms sending, but now I'm trying to set up the correct parameters for the sms receiving....It seems that the routine above posted that I'm using for that it's not working or I'm not handling right the serial port configuration...should change any other parameter else for the receiving?

I've got an old step-by-step guide for the SLC serial port configuration but it's not helping quite much...