5069-Serial ASCii Transmit Issue, Pics Inside.

so im trying to get ASCii data from a 5069-L306ER with a 5069-SERIAL attached to it and i have done it successfully but im having a few nagging issues. I have done this many times with a Micrologix 1400, using the same panel mount printer im using now with the Compactlogix.

Attached are two shots from the Powerpoint from AB for how to use the module. As well as two screenshots from HypeTerminal for what i get from a Micrologix 1400 and the Compactlogix when attempting to do the same thing.

With the Micrologix the CR and LF seem to work as they are supposed to. With the Compactlogix the CR and LF do not seem to work properly with HypeTerminal, although when printing to the panel mount printer, it seems to work as it should. Im confused as to why its not working the same way with both controllers, i would like to get it to work properly with Hypeterminal so i can write code, troubleshoot code, etc with the Compactlogix as i do with the Micrologix.

What is the exact contents of the string you're feeding to the 5069 module output .TxData array ?

It looks like you don't have CR and LF in between those readable text segments.

I think the String that feeds that array should be:


Studio 5000 uses some archaic nicknames for control codes; $N means two bytes, "Carriage Return and Line Feed",as "Newline".

You can also be explicit and designate both CR and LF as $R and $L.

Ken Roach said:

What is the exact contents of the string you're feeding to the 5069 module output .TxData array ?

It looks like you don't have CR and LF in between those readable text segments.

I think the String that feeds that array should be:

Code:

DATE :[B]$N[/B]TIME :[B]$N[/B]OPERATOR :[B]$N[/B]BATCH ID :$NRECIPE NAME :[B]$N[/B]

Studio 5000 uses some archaic nicknames for control codes; $N means two bytes, "Carriage Return and Line Feed",as "Newline".

You can also be explicit and designate both CR and LF as $R and $L.

Code:

DATE :[B]$R$L[/B]TIME :[B]$R$L[/B]OPERATOR :[B]$R$L[/B]BATCH ID :$R$LRECIPE NAME :[B]$R$L[/B]

Click to expand...

Ken, glad you chimed in because from reading this forum for a few years you seem to be one of the best that actively posts on here. Ive been playing with this the last few hours and i will post some other screenshots in a few, bare with me but i think i figured out what you posted above and im just not sure how to fix it.


So Rung 11 is where the 'append' of the delimiter characters is supposed to happen. Which I have as the number 10, which i thought based off of some ASCii charts should be the equivalent to $0A/LF. So, i setup CH0 on the module to look for termination delimiter $0D and $0A, CR and LF respectively. I then setup the module for termination mode to include the termination delimiters in the data thats sent out of the serial port. But if you look at the [13] element of that .TxData array its only reading a "$l", which isnt right because i would assume that should read "$0A", which is what i thought the 10 in the FFL would get me. That .TxData i changed the style from Decimal to ASCii to better see what was going on. So i think i SEE where im having an issue, but not sure why its not working nor how to correct it.

Does the panel-mount printer expect both CR and LF at the end of each line, or just LF between each line and CR LF at the end of the whole string ?



I think that the example that A-B gives with $00 $00 at the end of the string is for an application where you want everything in the string, and nothing else.

When you want to let the module itself add CR LF after each transmission, you don't add anything extra to the string, but you set up the 5069 module to "include" CR and LF at the end of the transmission.

Because I think you want CR and LF between each "LABEL :" section, I think you should follow the PowerPoint example precisely, and add both CR and LF in between your "LABEL :" sections in the string.

doing some more digging, a Rockwell document with ASCii string for Studio 5000 it has a character chart which shows the following.

[ctrl-J] LF 10 $l ($0A)
[ctrl-M] CR 13 $r ($0D)

so it does seem that the $l that I am seeing in the .TxData that im sending out of the port is correct.

Now, maybe i need to also get the $r on the end of that .TxData array as well?

Ken Roach said:

Does the panel-mount printer expect both CR and LF at the end of each line, or just LF between each line and CR LF at the end of the whole string ?

Good question, not sure of the answer, im just working off the fact that i send both the CR and LF at the end of each string using an AWA with a ML1400. So knowing that the printer works with that method i was trying to accomplish the same thing here.

I think that the example that A-B gives with $00 $00 at the end of the string is for an application where you want everything in the string, and nothing else.

When you want to let the module itself add CR LF after each transmission, you don't add anything extra to the string, but you set up the 5069 module to "include" CR and LF at the end of the transmission.

Because I think you want CR and LF between each "LABEL :" section, I think you should follow the PowerPoint example precisely, and add both CR and LF in between your "LABEL :" sections in the string.

Click to expand...

I do want it at the end of each string, so Date: (CR,LF) Time (CR,LF) etc etc

So doing some more testing capturing with RealTerm, it seems as if the issue is that the module is sending all of the NULL characters in the .TxData as well, which is why i assume its not being displayed properly on the HypeTerminal program. Anyway, even following the PP directly and using the FFL as 0 length of 2, you get what you see on the attachment.

So i was under the impression that you had to load the delimiter characters into the .TxData tag, and that once the controller 'saw' one of them it then knew that was the 'end' of what needed to be transmitted so it sent everything in front of the delimiter bit and then went about its next operation.

So i was under the impression that you had to load the delimiter characters into the .TxData tag, and that once the controller 'saw' one of them it then knew that was the 'end' of what needed to be transmitted so it sent everything in front of the delimiter bit and then went about its next operation.

Click to expand...

Thanks for bringing that up. I checked out Page 32 of the User Manual for the 5069-SERIAL.

The default Transmit mode is "ignore end delimiter", which simply transmits the number of characters in the .TxDataLength field when you increment the TxID value.

When you set up the Transmit mode to "Include Delimiter", the module searches for the delimiter characters and uses them to determine the length of the data to be sent. It then includes the delimiter characters in the transmission.

You could do that if your strings included just one "LABEL :" per line. I can't tell for sure if you are incrementing the TxID for each line, or if you're trying to send one string with multiple "LABEL :CRLF".

It makes sense to me now why the Rockwell example shows setting up the Transmit Delimiters to 0x00 and 0x00, then appending two null bytes to the end of the string in the TxData array.

That makes the module look for 0x00 0x00 to determine the end of the string.

I would do this with the 5069-SERIAL set up to "Ignore End Delimiter" (and the delimiter characters set to 0x00 and 0x00) and just put the correct length into TxDataLength.

so the code i didnt screenshot is an FFL and FFU that i use as a 'buffer' to send one string at a time out of the serial port. i figured that would be easier then trying to load that .TxData SINT up with numerous strings and trying to put the CR and LF in there where i needed.

So, i would like to send a string LABEL : (CR,LF) then send the next line LABEL : (CR,LF)

The other strange part to me here is that with the way i have it setup currently, Include End Delimiter, I would assume that the module would search for the delimiter in the .TxData SINT im trying to send then it would send everything before it out of the port. If thats the case then why do all of the NUL characters get pushed out as well according to RealTerm?

I only set my code up to put ONE delimiter character on the end of the .TxData tag. So i thought maybe that could be an issue as to why all of the NUL characters were being sent. What i did was change the FLL instruction a bit and added a second one so it added CR and LF to the .TxData tag, sent that from the module, and saw no change from how it acted. Ill grab some screenshots to make this easier to follow.


Screenshots with the FFL for the TxData being setup as just 10, then 10 and 13 to match the delimiter characters used in the module setup. both print a bunch of NUL characters and dont accomplish what im looking to do.

Second post just to attach more pictures

Ken Roach said:

When you set up the Transmit mode to "Include Delimiter", the module searches for the delimiter characters and uses them to determine the length of the data to be sent. It then includes the delimiter characters in the transmission.

That makes the module look for 0x00 0x00 to determine the end of the string.

So, if thats the case Im just confused as to how my method originally didnt work then? Im setting up the module to look for termination delimiters $0D(CR, $R) and $0A(LF, $L). In my code i then had the string that i watned to send with the $L on the end of it, so my assumption would then be that the controller sees "TESTING :$L" and then determines that everything before the $L needs to be sent out of the serial port. It would then include the modules configured delimiter characters, so long as it was set up to do it properly, which would be $L and $R. So the device on the receiving end of the serial port would be getting "TESTING :" (CR,LF)


I would do this with the 5069-SERIAL set up to "Ignore End Delimiter" (and the delimiter characters set to 0x00 and 0x00) and just put the correct length into TxDataLength.

I did just that, see attached pics

Click to expand...

I set the module up to ignore the end delimiters and then just concatenated the $R, $L on the end of the string that i wanted to send out of the port. Changed the code to write that string length to the TxDataLength then sent that all out of the port and RealTerm receives it just as it should! The strange part is that Hype!Terminal, the other serial capture program i have which i HAVE used in the past and it properly displays serial data from a ML1400, it still just receiving the same stuff RealTerm is but its just showing in a continuous line, almost as if the CR and LF aren't there.