I also noticed the discrepancy, but I initially thought it might have been a misinterpretation or a typo. Based on the screenshot provided, it appears that the monitoring is being done in Unsigned Decimal, displaying a value resembling "&65535". Even if the value is 32-bit, monitoring the 16-bit register would yield the same result as the upper word is disregarded. If monitoring in Double, the value would appear as "&65535,D". I made sure to confirm the conversion value (raw input) configuration, which is as follows: 0, -32768, 32767, CIO2007, Signed decimal.
The programming of all production lines follows this specific format. The readings from IO_Rack may sometimes display &65535. According to chelton, "The numbers in brackets represent different instruction types. (310) indicates an unsigned less than instruction, while (312) represents a signed less than instruction." To clarify, it appears that address (310) reflects an unsigned value, while S(312) signifies a signed value. Have you considered using S(310) instead? Although I primarily work with AB programming, I am currently reacquainting myself with Omron CJ2M plc's after a 30-year gap. Appreciation to everyone for their assistance. - James
In response to James Mcquade's inquiry about addressing values (310) and (312) in Omron programming, it is important to clarify that these numbers do not actually represent addresses. Instead, they are internal references known as Function Codes within the Omron system. Unlike traditional address-based systems, Omron instructions do not require a specific address to function.
When using comparisons such as "<" for Less Than operations in Omron programming, it is essential to understand the differences compared to other systems like Allen Bradley (AB). In Omron, the instruction itself dictates how the function is executed, requiring careful consideration and selection of the appropriate code:
- <(310) : Less Than, Unsigned
-
When analyzing digital values on a MAD42 card, it is crucial to understand the difference between signed and unsigned integers. The [<] instruction on this card compares 16-bit integers, with (310) representing unsigned values and (312) representing signed values. However, it is important to note that the instruction does not consider whether the values were originally written as signed or unsigned.
Therefore, it falls on the programmer to accurately interpret the 16 bits of each integer to determine if they are signed or unsigned values. In cases where the MAD42 card writes an integer as a signed value (e.g., [email protected]), and the signal can be less than 4mA resulting in a negative value, it is recommended to utilize the [<] (312) version of the instruction for comparison.
Each bit in a 16-bit integer holds a unique power of two, with Bit 15 being particularly significant. For example, for a value of -16384 in a signed integer interpretation, Bits 15 and 14 are set to 1.
It is essential to understand the implications of interpreting these 16 bits as either signed or unsigned integers. For instance, when the incoming signal is below 4mA and a negative signed value like -400 is written to the 16 bits (with Bit 15 as -32768), the [<] (310) instruction may interpret Bit 15 as +32768, leading to incorrect comparisons.
In conclusion, while this process may seem complex, it is crucial for accurate data interpretation on the MAD42 card.
I admit that I misinterpreted the confusion. Great work on the Two's Complement tutorial! The presentation is well-organized. I struggle with simply attempting to edit out my errors.
IO_Rack noted a misunderstanding and praised the Two's Complement lesson's clear formatting. It can be challenging to correct errors effectively. The key point is that a PLC program interacts directly with PLC memory, which consists of bits. Interpreting these bits, whether individually or in groups, depends on the context. In A-B/Logix, the data type of a tag is defined to determine how a group of bits is interpreted. In Omron, the choice of instruction dictates the data type and number of bits, with no explicit declaration in the data. This system operates similarly to assembler language.
In summary, Programmable Logic Controllers (PLCs) follow instructions precisely, without intelligence or adaptability. When a PLC is directed to interpret a set of 16 bits at a specific address as an unsigned integer, it will execute that instruction without alerting the user if another instruction treats the same 16 bits as a signed integer. This lack of awareness in PLC programming can lead to errors and discrepancies in data interpretation.
drbitboy explains that in Omron, the data type and number of bits are determined by the specific instruction selected, such as 310 or 312. The only information provided to the instruction is the address of the initial bit in the group. This process is similar to assembler language. One notable feature of Omron is the ability to assign a data type through Symbols, although this does not change how the instructions are carried out. If there is a mismatch between the assigned data type and the instruction data type, a warning will be issued. While some may find this aspect daunting, others see it as a helpful convenience. Despite initial confusion, long-time users of Omron eventually appreciate this feature.
drbitboy suggested that any software issue can be resolved by adding another layer of indirection. This approach may have been influenced by Omron's perspective.
Thank you, drbitboy, for clearing that up. I've been swamped all day. Much appreciation to everyone for their contributions. - James
If the Omron analog input drops below 4ma, you will need to implement a workaround in your programming. There are pros and cons to consider. An advantage is the ability to detect values below 4ma, while a disadvantage is the visibility of the input reaching 32000 and indicating disconnection. If you need more information, feel free to ask and I will provide a response. I frequently work with Omron products, which are my preferred choice for PLCs and software. Apologies for the brief message, as I have been very busy lately. I recently had a short break over the Christmas period, only taking time off on Christmas and Boxing Day. I have been working tirelessly on other days, even dealing with the frustrations of AWS (Amazon Web Services). Despite the challenges, I will continue to work with them as long as they pay the bills.
BobB, based on the logic I shared earlier, what workaround would you recommend for my issue? I'm struggling to make the < S(312) command work, even though I've been using Omron for years. Can anyone provide the correct syntax for the < S(312) command? - James
SEO-friendly Version:
BobB, what workaround do you suggest based on the logic I shared earlier? I'm unable to get the Omron < S(312) command to work, despite my experience with the system. Can someone please share the correct syntax for the < S(312) command? - James
James Mcquade is seeking assistance with implementing the < S(312) command and encountering difficulties in making it work successfully. Have you managed to edit the program yet? It would be helpful if you could provide a screenshot of your current progress. Furthermore, James Mcquade is requesting guidance on how to input the < S(312) command. To do this, simply double click on the instruction in edit mode, type in "
Thank you, IO_Rack, for pointing out my mistake. I appreciate your help in clarifying the issue. - James
Apologies for the delay, I've been occupied. If the number in the channel reaches around 65000, it indicates that the input has fallen below 4ma, which can be valuable information. On the other hand, if the number stabilizes at 32767, it signifies a disconnection, which is also helpful to know. This is achieved using the UINT data type. By writing specific code, you can set up a system where a value of 0 is stored in memory if the number exceeds 60000, serving as an alarm or warning for when the input drops below 4ma.
I want to express my gratitude to everyone who assisted with manually refilling the tank while I was away. Unfortunately, the tank was overfilled, causing water to spill everywhere. I plan to try adjusting the tank level in a few weeks during its cleaning. - James
James Mcquade recalled a chaotic moment in a pigment plant when an overfilled tank caused water to spill everywhere. As a young engineer working as a contractor of a contractor, he found himself in a sticky situation. The plant supervisor burst into the control room covered in yellow pigment, accusing the team of tampering with a valve that led to a 50,000 gallon tank overflowing. Despite the accusations, Mcquade's boss maintained their innocence and the team continued their work on another system.
This experience taught Mcquade the importance of loyalty in such high-pressure environments. It serves as a reminder of the importance of staying true to your team and not succumbing to blame in challenging situations.
James Mcquade mentioned that he would attempt to address the issue when the system needs to be emptied for maintenance. If you are still encountering problems with signed and unsigned values, consider maintaining unsigned values and incorporating a "> 32767" condition along with conditions "< 840" and "< 1048" simultaneously. This approach is based on the concept that a value greater than 32767 signifies a negative signed value for the level, which should be lower than the positive comparison values (840 and 1048). The significance lies in bit 15 of the 16-bit integer, determining whether it is signed or unsigned. Bit 15 adds a value of 0 or +32768 for unsigned integers when set to 1, resulting in a range of +32768 to+65535. On the other hand, for signed integers, bit 15 adds a value of 0 or -32768 when set to 1, leading to a range of -32768 to -1. This means that the bit pattern 0x8000 corresponds to -32768 or +32768, and the bit pattern 0xFFFF corresponds to -1 or 65535, for signed or unsigned integers, respectively.
drbitboy mentioned that for those still struggling with the issue of signed vs. unsigned values, it may be worth considering a solution that involves keeping values as unsigned and including an instruction that checks if the value is greater than 32767 while simultaneously comparing it to specific values. This approach can help identify cases where an unsigned value is actually negative, allowing for proper comparisons. Another option suggested is to monitor bit 15 for potential issues.
Attached is a zipped cxp file named "sample." The code is capable of detecting various conditions, such as exceeding 65000 (less than 4ma), reaching 32767 (disconnected), or surpassing >8100 (overrange, typically indicating sensor failure). If any of these conditions are detected, the value of 0 is written into the work word; otherwise, the input value is recorded. While not flawless, this will provide you with an overview of the code for handling these scenarios. Currently located in remote outback Queensland town of Cunnamulla, known for its cattle country and delicious steaks at local pubs. Fresh vegetables are scarce, usually available only one night a week, but there is an abundance of salad. In the midst of commissioning a hot springs complex utilizing bore water rich in sulfur, resulting in a distinctive aroma in the morning showers. Evidently, sometimes one may find themselves wondering, "What stinks? Oh, it's just me LOL."
Today, I had the chance to work with BobB and IO_Rack on an Omron system, focusing on the