Recently, I reviewed some of my previous code and noticed that I'm utilizing COP instructions to extract data from the dataman and transfer it into a designated string tag. Additionally, I employ the MOV instruction to assign a specific value to the .len attribute associated with that string. This .len attribute is further utilized in my COP instruction to define the string's length. Notably, both the MOV and COP instructions are implemented within the same rung, allowing for simultaneous data transfer and length specification. This streamlined process enhances efficiency and accuracy in data handling.
The barcode information for Cognex in my application is represented by CCataMan_SINT32:I:0.
Have you explored the Logix 5000 programming examples offered by Cognex?
alive15 mentioned: Upon reviewing some of my earlier programming work, I noticed that I'm utilizing the COP instruction to retrieve data from the dataman and transferring it into a string tag. Additionally, I'm employing the MOV command to assign a value to the .len attribute of that string. This same .len attribute is also being used in my COP instruction to define the string's length. On the same rung, I'm simultaneously using both MOV and COP instructions, which allows me to set the length and transfer data nearly concurrently. However, it's during the execution of the COP command that the .LEN attribute becomes incorrect. I'm seeking guidance on how to obtain the correct .LEN value. A SINT value of 256 or 484 is crucial for accommodating the recipe data.
Certainly! Here's a rephrased version of your text optimized for quality, uniqueness, and search engines:
You have the flexibility to define the desired .LEN value. Take a look at this image illustrating my current process. I'm utilizing the MOV command to transfer the specific length I want into my string's .len property.
I'm working with SINT32, but since I only require six units, I've set the string length to six. On the other hand, if you're working with SINT256 and need just 200 units, you should assign 200 to the .len property of your string tag.
The barcode's length will vary because the recipe instructions can range from 5 to 20 steps, and it will also be influenced by changing user data. Consequently, the barcode length could range from 50 to 400 characters.
Question for the Original Poster: What led you to assume that everyone would inherently understand that the Cognex device was transmitting data to an Allen Bradley PLC? Inquiry for alive15 and widelto: How did you determine that the question was related to Allen Bradley equipment? Is this specific Cognex scanner model exclusively designed for compatibility with Allen Bradley systems?
The .LEN value is being incorrectly overwritten with an invalid number. To fix this, open the monitor for the specific string, use CTRL-C to copy, delete the incorrect string, and then use CTRL-V to paste it back correctly, allowing the .LEN to be restored to its proper state.
To troubleshoot the problem of the .len being overwritten, it's crucial to pinpoint both the cause and timing. Does this issue arise each time you scan a barcode? Does it occur sporadically every five minutes, or perhaps even when you're merely pulling the trigger without scanning? Deleting and recreating the tag to resolve the length shouldn’t be necessary. Additionally, consider whether the barcode itself might be problematic. Have you verified the accuracy of the barcode you're using? Is it sourced from a website, or did you obtain it from elsewhere? Please review these aspects and provide more details. @Steve Bailey, I realize now it was naive of me to assume it was A.B. Initially, I noticed the .len in the first post, followed by the tag "CCDataMan_SINT256:I:0," which reminded me of RSLogix programming. My experience is limited to A.B. PLCs, so I couldn't relate this to other contexts.
To determine the character count within your string efficiently, you can utilize the FSC instruction, ensuring the string remains uninterrupted by blank characters. I created a User-Defined Data Type (UDT) for a string with a capacity of 484 characters, followed by establishing a tag named HandScan_String of this data type. This setup is designed to store the scanner results and transfer the FSC.pos value into its length seamlessly.
User alive15 mentioned that the .LEN parameter should be customized according to your needs. Here's an image of my current setup. I'm using the MOV command to specify any desired length for the string's .LEN attribute. For further details, click to expand. I successfully completed the task by implementing a method similar to yours. Specifically, I utilized the .MOV command to insert a value of 400 into the .LEN attribute after the data transfer, as this will always be the required length for the barcode. Thanks for the guidance! Celebrating with a beer now!
Steve Bailey posed a question to the original poster: "Why did you assume that everyone would instantly realize that the Cognex scanner is transmitting its data to an Allen Bradley PLC?" Additionally, he asked alive15 and widelto, "How did you determine this was related to an Allen Bradley PLC? Is this specific Cognex scanner model exclusively compatible with Allen Bradley?" To elaborate, Steve mentioned, "Frankly, I'm not aware of the specific PLC the original poster is using. I own the same Cognex scanner in conjunction with Allen Bradley and have encountered no issues whatsoever. Perhaps it was the FIND instruction that led me to associate it with an Allen Bradley PLC."
This revision incorporates commonly searched terms such as "Cognex scanner," "Allen Bradley PLC," and "compatible," enhancing the text’s search engine optimization.
KE8FDT reported success by utilizing a method similar to the one you suggested. I transferred a .MOV value of 400 into .LEN, which is always the length of the barcode, right after the data was processed. Thanks for the helpful hint! Time to celebrate with a beer!! Great job and congratulations on your achievement!