To activate a scanner, I typically adjust the values according to my needs. In my case, the values for triggering the scanner are SYN, T, CR, which correspond to 22, 84, 13 in the code. Please refer to the accompanying picture for more details.
After analyzing the screen shot of your communication software, it is evident that the device utilizes the "end-of-text" character (ASCII 03) as the terminator for messages. To efficiently handle varying response lengths from the device, configuring the 232ASC module to read until this delimiter is recommended. Attempting to input $03 directly into the configuration field as shown in your Capture2.png proved unsuccessful as it only accepts typical ASCII delimiters. Instead, the solution was to input the value 3 directly into the module configuration data found in the Controller Tags, as depicted in your Capture1.png: ENTR:6:C.ReceiveEndDelimiter. By using this delimiter, the ENTR:6:I.ReceiveRecordNumber will increment with each device response, indicating that data can now be extracted from the receive buffer.
RAYBRITO mentioned using a specific code to trigger a scanner, suggesting that users adjust the values as necessary. In his case, the code includes SYN, T, CR, represented by 22, 84, and 13. He also shared a picture for reference. Hey Raybrito, this looks promising. Do you happen to have any screenshots of your controller tags available as well? Thank you.
Apologies for the wait...
Commonly searched terms in digital marketing, tags play a crucial role in optimizing website performance and increasing visibility for specific keywords.
Hello everyone, I want to express my gratitude for the responses I've received so far on this forum. I have been experimenting with getting the 1734-232ASC to transmit data successfully. However, it seems like I may be encountering issues with the way I am sending out the data. I have included numerous screenshots for reference in the hopes that someone can help identify where I may be making mistakes. The ladder diagram illustrating my attempts is attached as well. I have organized all the necessary commands in a command array, along with showcasing the output from the 1734-232ASC card and the card's configuration. Your detailed feedback would be greatly appreciated, as my skills in PLC communication are still relatively new. Thank you once again.
Thank you for sharing those screenshots! I have some recommendations and considerations to improve the functionality. Firstly, consider adding a one-shot as a rung condition with the Foot Pedal. This will allow the ADD instruction to increment the .TransmitRecordNumber every program scan while the Input is high, resulting in rapid transmissions. Secondly, determine if your terminal emulator software sends a Carriage Return or a Carriage Return and Line Feed after each line. The 232ASC only supports one automatically-appended Termination character on the Transmit side, so ensure this is configured correctly. Additionally, investigate why O.Data[0-3] shows 0,0,0,$04 instead of "/1ZR" and review the logic to identify any unintended data transfers. Please provide more details on the successful terminal emulation you previously mentioned, especially regarding the presence of CR or CR+LF at the end of each ASCII transmission.
Hello Ken, thank you for the information. I have included my program in a Zip file, along with a section from the manual detailing communication in the other two. Please take a look when you get a chance to see where I may be going wrong. I will also try out your suggestions in the morning. Thanks once again.
Are you able to utilize serial port monitoring software to track the data transmitted by a specific program, as well as the data being sent by the 232ASC device? I have successfully utilized the free serial port monitoring download available at http://www.serial-port-monitor.com/free-serial-port-monitor-downloads.html. Feel free to use the software that you prefer and are comfortable with for this task.
When using the copy command, make sure to specify the correct starting location. In this case, it should be Data[0] instead of Data[4].
I want to express my gratitude to Mispeld for pointing out a detail that I overlooked. The String data must be correctly copied from element 0 of the .Data section of the String into the Output data array, starting at element 0. The String datatype begins with a DINT for the Length, and the issue causing CommandArray[0] to land in O.Data[4] through [7] has been identified. This explains the presence of the isolated value "4" in the Output data.
Please refer to the attached screenshot for guidance on writing the logic to display the Command_Array[x] Strings to the 232ASC. I have separated the increment of the "Transmit Record Number" onto its own rung not only to prevent repetition but also to highlight the importance of considering module RPI expiration when modifying Output data tag elements. This is crucial, as the expiration can occur at any point, even between elements of an array-tag COP instruction, necessitating the use of the Copy Synchronous (CPS) instruction.
In the event of RPI expiration during or after the COP, or after the MOV in Rungs 1 or 2, the Output data image will be sent out with the unincremented Transmit Record Number, resulting in non-transmission of data and preventing undesired operations. By ensuring that the O.TransmitRecordNumber only changes in the last MOV instruction on Rung 3, the risk of the 232ASC receiving incomplete or incorrect Output data is eliminated.
The 232ASC/485ASC module is a sophisticated piece of technology inspired by a DeviceNet/Serial module from Western Reserve Controls in Akron, Ohio. The Prosoft ILX34 modules are also based on the same hardware design. This stable and reliable design, which I have been familiar with since around 2003, effectively performs its intended functions without unnecessary complexity. Feel free to review the attached screenshot for visual reference.
Hello everyone, I have analyzed the two readings from the comports in hopes of gaining more insight into the data being transmitted. Any feedback on where I may have made a mistake would be greatly appreciated. Thank you once again.
The logic in your code is currently generating three null values and a 0x04 character. To fix this, implement the changes displayed in the screenshot above to ensure that your initial command string is properly sent, along with a Carriage Return (0x0D) character.
Hey Ken, sorry for the confusion earlier. I finished the code based on your instructions. When I checked the first array, all I saw was dots. However, in array 1, it displayed "\1A".
It appears that the destination has been correctly set to Output Data[0], but the source is still showing as the base String tag instead of the .Data[x] array. Please review the syntax carefully to ensure accuracy (refer to the screenshot with annotations highlighting the original incorrect address syntax in the inset box).
Hello Ken, I have successfully utilized your code to retrieve responses, as seen in the recent ladder update where I am now receiving ASCII characters. I apologize for the numerous questions, but I am unsure where to make changes to the .Data[x] array. Could this be found in one of the accompanying photos? Thank you immensely for your assistance in this matter, and I appreciate your patience with my limited knowledge in serial communication. Every day presents a new opportunity to learn and grow.
Noob_MW mentioned that they utilized your code as is to retrieve the responses, which are now displayed in the updated ladder. It is effectively capturing some ASCII characters. I apologize for the numerous questions, but where exactly can I make the change to the .Data[x] array? Is it in one of the other images provided? Thank you so much for assisting me with this issue, and I apologize for my limited expertise in serial communication. As they say, every day is a learning experience.
A bystander pointed out that in Rung 3, shouldn't the LES be changed to LEQ? Otherwise, the Tx record number will become stuck at 254. Unless I am missing something? Additionally, should the GRT test be in the upper branch to prevent the Tx record number from jumping from 254 to 255 on the LEQ test, and then from 255 to 1 on the GRT test ("left to right, top to bottom"), all within one scan? Though this might not have a significant impact, it is worth considering.
Great insights on the increment test, and I must admit my oversight for not testing it initially. As you pointed out, the top instruction should be LEQ, while the bottom one should be GRT. This setup ensures that values range from 1 to 255 inclusively, without ever reaching 256 at the output due to the limitations of a SINT. I default to 1 as a precaution, as there may be considerations regarding the significance of 0 in the Tx Record of the 232ASC. I could simplify the process by continuously adding 1 to the TxRecordNumber, resulting in a rollover to -1 and subsequent countdown. However, I prefer maintaining a slightly more readable approach.
When using the COP instruction, make sure to specify "Command_Array[0].Data[0]" as the SOURCE value instead of just "Command_Array[0". While you have the option to expand the Database view using the Tag Picker's [+] icons, I find it more efficient to manually type in the details. You're almost done!
Hi Ken, I appreciate your help in getting the characters sent correctly this time. I have attached a picture for reference. I attempted to connect it to the pump, but there is no movement. Could it possibly require a carriage return or another step? Your assistance has been invaluable as we get closer to resolving this issue. Thank you.
Noob_MW commented: Hello Ken, I apologize for my initial response before seeing yours. I have implemented the code given by you and observed that the first array only displays dots, while the second array shows "\1A". In data 4, is the information from the provided software or from your PLC? It is crucial to ensure that the data sent matches what the software is expecting. Disregard the display on the right side showing ".../1A", focus on the hex values on the left. Note that before sending x2f x31 x41, you are sending x00 x00 x00. The ellipsis is shown because these hex values are non-printable characters that are represented by a dot.
After reviewing the user manual, I will include a screenshot of the important section. It is important that commands sent from the PLC to the pump are terminated with a Carriage Return byte. Replies from the pump should end with an ETX, Carriage Return, and Line Feed. In the data exchange captured, I did not observe a Carriage Return byte (hex 0x0D) following "/1AR". Please verify and adjust your Termination settings in the 232ASC configuration, ensuring that the termination is set to "$R" from the dropdown menu, and the Termination character for transmissions is enabled.
Hello Ken, I have included the configuration details from the module settings and controller tags. Should I simply append it to the string, or would that be an incorrect approach? Thank you once again.
Ken Roach suggested making the top instruction GRT and the bottom one LEQ to ensure values range from 1 to 255 inclusively, avoiding an output of 256 (since a SINT cannot hold this value). It seems that the correct order should be top GRT and bottom LEQ. Additionally, it was noted that the top GRT-driven MOV should transfer 0 (instead of 1) to TxRecordNumber when the rung begins with TxRecordNumber at 255, as the bottom LEQ-driven MOV will then increment TxRecordNumber from 0 to 1.
In a recent discussion, drbitboy suggested a different approach: placing top GRT above bottom LEQ in a sequence. It was noted that a top GRT-driven MOV should move 0, not 1, to TxRecordNumber when the rung starts with TxRecordNumber as 255. This adjustment ensures that the bottom LEQ-driven MOV will increment TxRecordNumber from 0 to 1. This concept is supported by experiments showing that only LEQ(val,N-1) at the bottom and GRT(val,N-1) at the top generate a sequence of 1,2,...,N. For instance, files 00incrementer_leq_top.RSS/.pdf and 01incrementer_leq_top_uploaded.RSS/.pdf demonstrate the process of incrementing the counter. On the other hand, files like 03incrementer_grt_top.RSS/.pdf and 04incrementer_grt_top_uploaded.RSS/.pdf showcase the impact of using GRT on the top to put either 1 or 0 into the counter. Through various scans, it was observed that the counter values fluctuated between 1 and 3 in different scenarios.
Another efficient method to streamline operations after parallel LEQ and GRT comparisons is to introduce an additional instruction. This approach can reduce the need for coordination downstream. Alternatively, a counter could be used for the same purpose, as long as it is not incremented during consecutive scans. See the image below for more details.
I am grateful for the helpful advice and suggestions you have provided. Thank you for your support and guidance.
Ken Roach mentioned that he reviewed the user manual and will share the crucial information as a screenshot. The PLC commands to the pump must conclude with a Carriage Return byte, while responses from the pump will end with an ETX, Carriage Return, and Line Feed sequence. In the communication log, the absence of a Carriage Return byte (hex 0x0D) after "/1AR" is noted. It is advisable to verify the Termination settings in the 232ASC configuration, ensuring that the termination for "$R" is selected from the drop-down menu, and the Termination character for transmissions is enabled. Is it possible to adjust this in the module configuration settings? Thank you.
I have made adjustments to the transmission string by including the start and end signals. However, I am encountering issues when attempting to send it to the unit. Is there something I might be overlooking in regards to the bits? Any advice on this matter would be greatly appreciated. Thank you.
Your Command_Array[3] string seems to have a 0x02 (hex) value placed before the forward slash. The rest of the command is accurate: /1ZR. To ensure proper execution, make sure the forward slash is the first character in the string. You're almost there!
Hello Ken, thank you for your response. I have tried using a modified array without the hexadecimal 02, which resulted in no movement detected by the monitoring tool when attempting to send. We are very close to resolving this issue.
Ken, you may not believe this, but I made a mistake and accidentally swapped the Tx and Rx while troubleshooting a monitoring tool issue. After realizing the error and correcting the wire positions, everything is now working perfectly. Your assistance was invaluable in resolving this issue that had me stumped. Thank you!
I am attempting to enable the Honeywell 1910i scanner using an RS232 command. While I successfully sent the command "\x16T\r\n" on a real terminal, I encountered issues when trying to do the same with a 1734-232ASC module. According to the scanner's manual, all I need to send is "SYN T CR" by writing "22" in the first array position, "84" in the second, and "13" in the third. Can anyone assist me with the correct string and data format to send to the scanner? Thank you.
snowman79 inquired about sending a specific string in a 1734-232ASC module, similar to the functionality on a real terminal. Despite following instructions in the scanner's manual to send "SYN T CR" by writing specific values in an array, the expected outcome was not achieved. The manual specifies sending the values "22", "84", and "13" to trigger the desired action, but a user suggested adding a fourth value of "10" for a linefeed. Can anyone provide guidance on the correct string and data format to send to the scanner? Any assistance is greatly appreciated.
As suggested by drbitboy, following the third occurrence of "13," proceed to send the fourth "10" character, which is also known as a linefeed. I appreciate the advice and will attempt this again tomorrow, providing you with any feedback afterwards.
It is working perfectly now. I appreciate your assistance.
User snowman79 expressed gratitude, stating that everything is functioning well with a simple "thanks for your help." Just to clarify, the intention was to "linefeed a.k.a. newline." You're welcome!
Mispeld suggested starting with the POINT I/O ASCIIModules 1734-232ASC & 1734-485ASC. However, this manual primarily covers Devicenet rather than Ethernet for the protocol. Despite searching through the manual like the original poster (OP), I did not find the information I was looking for.
Newbie Noob_MW is seeking assistance in sending ASCII characters to a unit that performs tasks through a 1734-232ASC module connected to a 1734-AENTR series B Point IO, and then to a CompactLogix L36ERM PLC. While having some success using desktop serial connection software, Noob_MW now aims to transmit data via PLC. Assistance is sought in setting up strings and ensuring accurate data transmission. Feedback and examples for sending strings to a Chroma power supply via RS232 are also welcomed. Your insights are greatly appreciated.