When using the IO_Rack system, I can use the UP521 command to turn on a valve with the tag name Charge for 1 scan before turning off. This command can be used as many times as needed. Additionally, I am looking to find free memory areas within the program. This becomes important when dealing with timers, counters, and bits. Any guidance on locating these free memory areas would be greatly appreciated. Thank you in advance, James.
In the example I mentioned earlier, the W12.01 variable will only be active for one scan of the PLC, allowing you to use it multiple times in your program. This confirms the validity of the statement. To access the Cross Reference feature, go to the View menu and select it. When searching for available memory, I usually opt for the 'Usage Overview Including Unused' option as the Report Type.
It seems that the original poster (OP) is interested in utilizing the "ons" function on a contact with an arrow indicator. It has been a while since I worked with OMRON, but I believe it is similar to Mitsubishi in that you should be able to use any boolean bit, such as an input marker, multiple times without needing to create a oneshot or similar output function. In Mitsubishi programming, there are draggable contacts with arrow indicators that can be reused multiple times, unless the toolbar settings have not been properly configured.
Thanks for the input on IO_Rack. It can be challenging to find the AB type format when working with Omron PLCs, but it's essential for consistency in the program. It seems like the original programmer scattered bits all over the memory map with a shotgun blast from 50 feet away.
I agree with Parky about maintaining the program format for consistency. I want to ensure that the new team member starting soon can easily understand and work with the existing program. Thank you to everyone for your insights and suggestions. - James
Hello James, I haven't had the chance to explore the latest Omron IDE yet. Have you managed to locate the rising edge contact?
I will write the code once the ongoing fire is extinguished. Thank you all, James.
Thank you IO_Rack for the various options provided. I have confirmed in simulator mode that the up arrow contact should only operate once, as you mentioned. However, on the actual PC, it sometimes operates 2 or 3 times during a scan. I will further investigate this on Thursday. In the meantime, I have added the UP(521) in series and it is functioning correctly. Increasing the line speed by 10% resulted in the logic functioning as expected. It is possible that there is a software or PLC firmware bug, so I plan to contact Omron tomorrow. Thank you to everyone for your help. - James.
James Mcquade mentioned that he confirmed this issue in simulator mode, but it sometimes occurs 2 or 3 times during an actual scan on the PC. James, have you utilized any increment instructions in parallel to verify this issue? It might be worth investigating if this is related to an input problem. Implementing buffering or debounce techniques could potentially resolve this issue.
I have never encountered this issue before, but it seems James may be mistaken or there could be a malfunction. Typically, the CJ series is only used for one scan, although I have seen it utilized in other people's code.
James McQuade expressed his gratitude to IO_Rack for providing various options. Upon testing, it was found that the up arrow contact should only trigger once, as discussed. However, in some instances on the actual PC, it operated 2 or 3 times during a scan. Further investigation is underway and a fix has been temporarily implemented by adding the UP(521) in series, resulting in the correct operation of the logic. Increasing the line speed by 10% yielded the expected results. It is possible that there might be a software or PLC firmware bug, prompting a call to Omron for assistance. Despite this, McQuade deems it highly unlikely that the issue lies with the PLC firmware.
At chavak, our machine operates at a speed of 40 strokes per minute. When the cylinder cycles, I program an instruction to monitor the speed. If the speed exceeds 40, the servo speed is decreased by 10 rpm. While observing online and on the HMI, the rpm varied from 3900 to 3880 or 3870 multiple times in one cycle. I confirmed this three times. After implementing the up command, the issue was resolved. The cylinder remains in the down position for at least one second without any issues. Though I am still in the process of learning the Omron system, I would have agreed with you if the HMI had not shown a similar scenario. As I did not create the initial code, there might be something overlooked. - James
Our machine operates at a speed of 40 strokes per minute using a servo system, but it can reach up to 60 strokes per minute. We have multiple machines feeding into the production line, with a limitation of 120 products per minute to prevent stress, breakage, or jams. Each machine calculates its production rate, and I designed a logic to adjust the speed if it exceeds 40ppm by a certain percentage. During testing, I noticed the speed dropping to 42rpm instead of 40 as intended, possibly due to a specific energized cylinder. After some troubleshooting on both the PC and HMI, I added an up command to resolve the issue. Despite initial challenges with the PLC code, I successfully optimized the logic by simplifying the rung and integrating the cylinder extend command. The system now operates efficiently as expected. Thank you for your understanding and support. - James.
During my observation both online and at the HMI (Human-Machine Interface), I noticed fluctuations in the RPM speed, specifically dropping from 3900 to 3880 or 3870 multiple times within a single cycle. Can you please clarify the definition of "1 cycle"?
The drbitboy filling machine operates by pressing the cycle start button, causing the pbservo to move to the correct position and the cylinder to extend, triggering the product to fall into the box for a specified time. After the cycle is completed, the cylinder retracts and the servo moves to the correct position for the next cycle. - James
In a previous post, you mentioned that an instruction is being executed multiple times during a scan, rather than in a cycle. When referring to "scan," I assume you are talking about the PLC program scan, which is a continuous task. To ensure we are on the same page, could you clarify if by "cylinder extends - this is the trigger," you mean this signal is the trigger point, where the rising edge prompts a speed calculation and possible adjustment to control speed? Is it possible that the "cylinder extends" signal may be subject to noise, similar to the bouncing effect seen in cheap pushbutton contacts during the transition from retracted to extended position? I agree with @lostcontrol that it is improbable for the instruction to be malfunctioning; rather, it is more likely that we need to better understand the timing of inputs to that instruction across multiple PLC program scans, potentially at a rate of 1kHz. I understand that you may have resolved the issue and moved on; please feel free to close this if it is no longer relevant to you.
It is important to mention that without any code provided, only one instruction given, it becomes challenging to determine the precise issue. Thus, we are left to speculate on the situation at hand.
Apologies for the rush earlier. I intended to refer to 1 cycle, not a scan. The trigger for extending the cylinder is indicated by the rising edge. A relay output card is utilized, along with 32-point CJ1W-OD232 modules. The cable connects to an output board, and I will further investigate this point. I am unable to share the code directly, but I can translate the relevant portion into English for our discussion. The OEM has classified it as confidential. As the production line is currently halted, I need to attend to it urgently. Thank you, James.
James Mcquade expressed his apologies for being in a rush and clarified that he meant there should be only one rising edge per cycle, not a scan. The trigger for extending the cylinder is the output that initiates the rising edge. A relay output card is utilized, along with 32-point CJ1W-OD232 modules. The cable connects to an output board, which is a significant aspect that will be further investigated.
Unfortunately, the code cannot be shared due to confidentiality reasons, so it will need to be translated into English for the specific part of the discussion. It will be explored if this can be done. The original equipment manufacturer (OEM) has designated the information as confidential. As the production line is currently down, it is imperative to address the issue promptly.
James Mcquade mentioned that he found the instruction in the KEEP(011) section after conducting a search. Click to expand and review the details. Additionally, it is important to investigate what might be causing this instruction to reset. Are you utilizing a HSC card for the servo? Is the affected code, or any other related part, within an Interrupt Task? Like others, the goal is not to dwell on this issue but understanding the reason for the discrepancy is crucial. Consider copying the code to a new project, removing comments, and sharing it to demonstrate how you implemented each one-shot method.
Resolved Issue: I made a significant adjustment to the PLC's rising trigger signal this morning by changing it to just the normally open contact. As I monitored the process, I noticed that the contact would intermittently turn on and off within the cycle. This issue seems to be within the OEM's logic, which is in a different language and requires a lot of Google Translate to decipher. Despite this, my boss is pleased with the program I have developed as it has effectively reduced machine downtime and prevented any crashes downstream for the past 24 hours. I have a query regarding how to include a rung comment in the logic. Thank you to everyone who provided assistance during this challenging process. I hope sharing this post will be beneficial to others. - James
To access the properties of the left bus bar, simply click on it and select "Properties" from the right-click menu. You can also double-click on the left bus bar to view its properties. Another neat feature is the ability to right-click on any contact or instruction and leave a comment with an anecdote. This adds a personal touch to your work and allows for easy collaboration.
IO_Rack mentioned a useful feature where users can comment with anecdotes by right-clicking on a contact or instruction. If you missed this option, simply right-click and select Properties. This feature is particularly helpful when commenting on large rungs. See the following example for more details on how to use anecdotes effectively.
Thank you for the information about adding rung comments online using AB software, IO_Rack. I have found that I can add rung comments offline and then go online to make them live. This process has been very helpful in optimizing my PLC programming workflow.
You can also complete this task through online platforms, especially with newer processors, by simply entering online edit mode.
Thank you for the suggestion, I will give it a try tomorrow. I am currently using Omron CX-Programmer version 9.75. Can anyone provide information on the most up-to-date release of this software? Appreciate any advice in advance. - James
The latest version available is Cx-P 9.82.
Ensuring that your Omron software is regularly updated is crucial for maintaining optimal performance. Omron is renowned in the industry for their exceptional backward compatibility. However, it's important to note that limitations may arise with certain processors. Don't worry, your CJ2M should still work seamlessly for online edits and storing comments.