adccommunitymod (AutomationDirect) asked a question.
Serial Comm's ASCII In command
Created Date: December 02,2003
Created By: jaurrichio
**** 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.****
Currently I have Port 2 set up as a Non-sequence Protocol, and trying to send Ascii strings into a V-mem location via the AIN command. Im using the DL260 CPU and to test the functionality I am simply using windows Hyperterm. I 've double check my baud rate, data bits, stop bits, and Parity - they are the same on both ends. Pins 4 & 5 (RTS & CTS) are jumpered together. If anyone has any suggestions they are appreciated. Thanks JOn
Created Date: December 02,2003
Created by: jaurrichio
Currently I have Port 2 set up as a Non-sequence Protocol, and trying to send Ascii strings into a V-mem location via the AIN command. Im using the DL260 CPU and to test the functionality I am simply using windows Hyperterm. I 've double check my baud rate, data bits, stop bits, and Parity - they are the same on both ends. Pins 4 & 5 (RTS & CTS) are jumpered together. If anyone has any suggestions they are appreciated. Thanks JOn
Created Date: December 02,2003
Created by: franji1
What parameters are in your AIN box?
You may want to disable the AIN and put in a PRINT box and see if the connection is working (you would see OUTPUT in Hyperterm). If this works, chances are your AIN box is not set up right.
Created Date: December 02,2003
Created by: jaurrichio
I was able to PRINTV to hyperterm from the DL260 it turns out that I didnt have a termination character for the AIN. Thanks for your help things are looking up.
Created Date: December 02,2003
Created by: chris.zeman
Wouldn't you know it, I was just logging in to post my own question regarding AIN. Here's the issue I'm having and maybe, just maybe, you 're running into the same problem I am.
I have already successfully used the ASCII In example program on a DL06 to read barcodes from redemption tickets. Now, here is where I run into trouble. I changed my AIN instruction to use status bits other than C0, C1, and C2. Once I do that, I can no longer successfully read receive the data. I thought that perhaps those bits had to be at the beginning of a memory address and made sure they were. I still have had no luck. Any ideas?
Chris
Created Date: December 02,2003
Created by: jaurrichio
Chris it doenst make sense, in the example program I viewed EP-COM-007, DL205 they used C100... C104 with the AIN command. Are you sure you changed all the bits throughout your logic?
Created Date: December 02,2003
Created by: chris.zeman
Positive. After it failed in my program I used the example program (EP-COM-008_06) and had it working. I then changed all the bits and it stopped working. I'm sure the problem is right in front of me. lol
Created Date: December 02,2003
Created by: chris.zeman
OK, so I decided to put the DL06 PROGRAM mode and then back into RUN mode. It started working. ??? oh well. hehehehe
Created Date: December 03,2003
Created by: franji1
Were you doing runtime edits!?! If you were, the state of the AIN instruction can get REALLY messed up if you are in the middle of receiving characters (you have no control over that), when you CHANGED the status bits from C0 to Cwhatever.
You may need to disable the AIN BEFORE doing any runtime edits that modify any of its parameters. OR, BEST YET, ALWAYS I mean ALWAYS, go from run mode to program mode, to make sure your AIN is truly reset. Again, this is ONLY when MODIFYING THE AIN instruction itself! You could imagine if you change the V destination address in a runtime edit IN THE MIDDLE OF A BARCODE TRANSFER - WHERE DOES THE DATA GO? (some of it at the old address? some of it at the new address? how long is the data buffer? etc. etc. etc).
Do you understand the issues? Be VERY careful when doing runtime edits with AIN (or doing a runtime edit with any other asynchronous instruction: RX, WX, PRINT, etc.)
Created Date: December 03,2003
Created by: chris.zeman
I see what you 're saying. I know it wasn't in the middle of a transfer, though. The reader and PLC are currently sitting on my desk. Anyways, I'm glad that's all figure out. http://forum1.automationdirect.com/board/biggrin.gif
Thanks,
Chris