adccommunitymod (AutomationDirect) asked a question.

ASCII RS232 from & to Click

Created Date: May 22,2016

Created By: RichW

**** This post has been imported from our legacy forum. Information in this post may be outdated and links contained in the post may no longer work.****

I fought this for some time without finding a solution, and eventually gave up and went to a DL06 - but I'd still like to make it work with a Click. I have a need to communicate short (under 128 character) messages via RS232 between the PLC to and a device in ASCII, ending with with a Cyclical Redundancy Check & Carriage Return. Something like: Hello World! or 48 65 6c 6c 6f 20 57 6f 72 6c 64 21 5B3D 0D I can construct the various messages in TXT + HEX for the CRC, or straight HEX, and I was able to calculate the Hex Crc, but unable to send it because: a) If I did it in TXT, the Clic insisted on changing the 583D hex CRC to ASCII 35 38 33 44 b) If I did it in HEX, the click limited me to 128 bits instead of 128 characters. Never tried the receive, but for send I tried everything I could think of, and eventually the best advice I could obtain was "Switch to a DL06 or Do-More " Can anyone propose a solution?


  • adccommunitymod (AutomationDirect)

    Created Date: May 22,2016

    Created by: RichW

    I fought this for some time without finding a solution, and eventually gave up and went to a DL06 - but I'd still like to make it work with a Click.

    I have a need to communicate short (under 128 character) messages via RS232 between the PLC to and a device in ASCII, ending with with a Cyclical Redundancy Check & Carriage Return. Something like:

    Hello World!

    or

    48 65 6c 6c 6f 20 57 6f 72 6c 64 21 5B3D 0D

    I can construct the various messages in TXT + HEX for the CRC, or straight HEX, and I was able to calculate the Hex Crc, but unable to send it because:

    a) If I did it in TXT, the Clic insisted on changing the 583D hex CRC to ASCII 35 38 33 44

    b) If I did it in HEX, the click limited me to 128 bits instead of 128 characters.

    Never tried the receive, but for send I tried everything I could think of, and eventually the best advice I could obtain was "Switch to a DL06 or Do-More "

    Can anyone propose a solution?

    Expand Post
  • adccommunitymod (AutomationDirect)

    Created Date: May 23,2016

    Created by: ljbeng

    Can you run 2 PRINT ASCII statements, the TXT goes first and when it's done the next ASCII send sends the CRC as Hex?

  • adccommunitymod (AutomationDirect)

    Created Date: May 23,2016

    Created by: RichW

    Thanks, tried that. It didn't work, but I can't exactly say why. As I recall HyperTerminal showed the first part, and the was "lost ".

  • adccommunitymod (AutomationDirect)

    Created Date: May 24,2016

    Created by: kewakl

    Did you have a terminator in the first send?

  • adccommunitymod (AutomationDirect)

    Created Date: May 24,2016

    Created by: RichW

    Thanks.

    Did not have terminator in first send. However, it is likely that I also just sequentially listed the two commands in ladder logic. I may see if I can resurrect the Click and program, and retry with an interlock. (i.e. use "Complete " flag prior to the second transmission.) Aside from the program being able to send out 128 characters hex, as documented, rather than only 128 bits - that seems to be the most promising.

    Running into nightmares with the more powerful DL06, as well. Just spent too long trying to debug in "Test Mode ". After a while, I got it to stop, start, single cycle, etc. Then test mode stopped and would not do any of those things. Support tells me that those things are "not supported ", and that they were surprised it worked at all. Documented in DirectSoft6 help, and accessible in the program, but not supported, and surprising that it ever works as documented.

    Sigh.

    Expand Post
  • adccommunitymod (AutomationDirect)

    Created Date: May 24,2016

    Created by: kewakl

    Running into nightmares with the more powerful DL06, as well. Any stats to backup this observation? (J/K)

    However, it is likely that I also just sequentially listed the two commands in ladder logic. I may see if I can resurrect the Click and program, and retry with an interlock. (i.e. use "Complete " flag prior to the second transmission.) Aside from the program being able to send out 128 characters hex, as documented, rather than only 128 bits - that seems to be the most promising.

    Yes, an interlock/small delay may be necessary - depending on enabling logic of the Send instructions

    Support tells me that those things are "not supported ", and that they were surprised it worked at all.

    Yeah, years ago I was told that the only way that a DL(whichever one fits in a 205 chassis that supports address pointers) years ago ] address pointer could be modified were ZEROING, INCREMENTING and DECREMENTING. Not So! It can be set directly to whatever value (within reason) that I need!

    Expand Post
  • adccommunitymod (AutomationDirect)

    Created Date: May 25,2016

    Created by: RichW

    Kewakl,

    Yes, it looks like with an appropriate delay, perhaps only to the next cycle, it will work with the Click.

    Any stats to backup this observation? (J/K)

    Not sure what you mean. Stats, no. Opinions, yes. I 've had trouble with when to use Hex vs Octal vs Decimal, of course. There is an "Out " box and "Out " coil, and that gave me fits for a while. Some timers take multiple memory locations, but no error is given if consecutive timer or counter locations are assigned overwriting the accumulator. It would be nice if the manuals were better indexed, the two volumes are more tutorial than reference guide. All learning curve stuff, and part of the process, but also needlessly difficult. Those are the nightmares - and I have woken in the middle of the night with "maybe if I convert to hex it will work " in my mind. The major aggravation, of course, was to find that the test mode, although in the program and documentation, simply doesn't work. "Oh, it's not supported " may be all the help line can say, so I can't fault them, but come on - is this a beta unit, or something that has been around for a while?

    Back to the Click, I gave up too soon. It's a nice unit, simple, easily programmed, and I can even do things like cut and paste a single contact or coil. Thanks again for giving me the nudge I needed to get back on track.

    Rich

    Expand Post
  • adccommunitymod (AutomationDirect)

    Created Date: May 25,2016

    Created by: plcnut

    Any stats to backup this observation? (J/K)

    Not sure what you mean. Stats, no. Opinions, yes.

    J/K = Just Kidding.

    I believe that kewakl was just being facetious. :)

  • adccommunitymod (AutomationDirect)

    Created Date: May 25,2016

    Created by: andremholmes

    Have you looked at the sample program to communicate with a barcode scanner?

  • adccommunitymod (AutomationDirect)

    Created Date: May 27,2016

    Created by: bgirouard

    One thing I want to get out of the way... If you are sending ASCII out from Click, you will have a lot of difficulty catching data on the return. Click RS232 is NOT asynchronous, so if you are able to get it to work at all, it will be a bit of a crap shoot on getting your ladder program to cycle through at just the right time and coordinate the external device to time its packets back. I was using ASCII commands to contol STP-DRV-4850 step motor drives, and could only get it working using one-way communication. My application had an operator supervising, so if it did not work, there was someone there to react to it accordingly.

    The DL06's internal RS232 port suffers a similar problem. The way around this (I found) is to use the coprocessor, which DOES offer asynchronous communication, as well as CRC, so it made life a lot easier.

    The Do-More does have asynchronous communication available, so if you want to upgrade to that, then it has more features that you can play with.

    Just my 2¢.

    Expand Post
10 of 47