Furthermore, it has come to our attention that the code contradicts the recommendation provided in a previous discussion. It was advised multiple times to utilize FIFOs to simulate the positions of boxes on the conveyor using array index(es). Another aspect to consider is the measurement for height (weight?) in the code, which only recognizes three specific heights (Teža za izmet 1/2/3). What would happen if a box of a height not included in the three specific measurements enters the conveyor system? Would it bypass all three rejection stations without being sorted?
Is it correct that Encoder Signal A is an edge signal that remains TRUE for only one scan cycle when each gear tooth is first detected?
Drbitboy noted that the code used deviates from the recommendation provided in previous discussions, which suggested utilizing FIFOs to track the positions of boxes on the conveyor. One query raised was regarding the code's handling of heights, specifically if a box with a height not specified in the code passes through. In such cases, the box will continue along the conveyor without being sorted, bypassing all rejection stations. This approach ensures that boxes outside the specified heights are not sorted and are allowed to proceed to the next conveyor.
"According to drbitboy, Encoder Signal A is an edge signal that remains TRUE for only one scan cycle when a gear tooth is first detected. Is this information accurate? This signal is generated by a proximity switch attached to the gear tooth."
In a discussion, DrBitBoy confirmed that while we have not seen all the code, specifically the logic responsible for assigning a value of FALSE to the Ejection stations (#Izmet 1/2/3), it likely involves a timer or counter. Is this assumption accurate? It turns out that the logic actually utilizes a sensor to detect the presence of a box, subsequently disabling the ejection process.
Zinko proudly stated that he did things his own way, even when boxes exceed the required height specifications. In this scenario, the box simply moves from one conveyor to another without being sorted. However, in the current process model, there may be a limitation in detecting when two or more consecutive boxes of the same required height are present, as the system is overlooking boxes with non-required heights. This oversight could potentially impact the efficiency of the sorting process.
According to Zinko, the signal from the proximity switch is crucial as it is attached to the tooth gear. Is this signal just a one-time occurrence, meaning it is true only once for each gear tooth detected during one PLC scan cycle? If the signal is not just a one-shot occurrence, then the Actual Position ("Dejanska Pozicija") could potentially be increased by 2cm multiple times for each gear tooth detection. This could result in the need to add 2cm to the Actual Position for each tooth detected, leading to potential inaccuracies in the positioning system.
In a software development setting, it's essential to ensure that the code can accurately identify consecutive boxes of the same required height. This can be achieved by inserting every height into an array, including those that may not be considered as required. By tracking the position of each box, the code can effectively handle different box heights and their sequences.
drbitboy inquired about the nature of the signal: Is it a one-shot signal that is only true once for each detection of a gear tooth during one PLC scan cycle? If the signal is not one-shot, there could be multiple increments of 2cm added to the Actual Position ("Dejanska Pozicija") for each gear tooth detection. The response confirmed that it is indeed a one-shot signal.
According to Zinko, the system employs sensors to automatically shut off the ejection process when a box is detected. Each sorting and ejection station is equipped with a sensor, which triggers the corresponding "Izmet 1/2/3" to be marked as FALSE upon detecting the sorted or ejected box. Can you confirm if this understanding is accurate?
drbitboy pointed out that there is a sensor at each sorting and ejection station. When the sensor detects the sorted or ejected box, it assigns a value of FALSE to the corresponding "Izmet 1/2/3." Is this the correct process?
Zinko mentioned that every height is added to the array to track the position of each box. However, it is unclear what value #Izmetalo will have when it is placed in the ejection position ("Pozicija za izmet") for the non-required boxes. The code does not explicitly show #Izmetalo being reset to zero after being set to 90, 150, or 190 in the initial IF-ELSIF-ELSIF-END_IF statements. This raises questions about the handling of #Izmetalo values for the non-required boxes.
drbitboy raised a question regarding the value of #Izmetalo set in the ejection position ("Pozicija za izmet") for non-required boxes. It seems like #Izmetalo is not being reset to zero after being assigned values of 90, 150, or 190 in the initial IF-ELSIF-ELSIF-END_IF statements. The code snippet checks if #"Teža za izmet 1", #"Teža za izmet 2", or #"Teža za izmet 3" is equal to #"Podatek teže do senzorja izhod" and assigns values accordingly. If none of the conditions are met, #Izmetalo is set to 500.
In the provided code snippet, Zinko introduces a condition for the variable Izmetalo and provides a clean and commented version of the code for better readability and understanding. The code snippet includes logic for determining the ejection position of boxes based on weight data and sensor output. It also includes a mechanism for updating the actual position of boxes and triggering the eject mechanism once a box reaches its designated ejection position.
To summarize, the code snippet optimizes the process of handling box ejection positions and ensures efficient execution based on various conditions and sensor inputs. Through the use of structured coding and clear comments, the code aims to streamline the box ejection process for improved automation and accuracy.
One important question is where, when, and why the program updates the value of #Head. It appears logical to do so within the "IF #"Bit helper" [3] AND ... END_IF" clause. It is assumed that the "Box data" array contains 30 elements, possibly representing more boxes than can fit within a 5m (500cm) system. An important distinction between my revised code and the original code is that the earlier version may not have been able to clear boxes with heights that are not required.
Inquiring about the moment and reason behind the program altering the value of #Head is crucial. This modification could ideally take place within the "IF #"Bit pomožni"[3] AND ... END_IF" clause above. It is presumed that the #Box data array containing 30 elements is designed to accommodate more boxes than the system can hold within a 5m (500cm) range. Notably, one distinction between the revised code and the original version lies in the ability to clear boxes with non-mandatory heights. Interestingly, once the head surpasses a count of 30, it resets to 0 since the Box data array consists of 30 tables. This marks a significant divergence between your code and mine.
To effectively deactivate the Thrower (Izmetalo), it is essential to establish two conditions. Here is a more detailed explanation for Eject 2 (Izmet 2 at 150cm): Firstly, set the #"Box data"[#d]."Ejection position" to 150 (#"Podatki Skatla"[#d]."Pozicija za izmet" = 150) as a one-shot conditional trigger, converting it to a bit (Boolean) named Eject trigger 2 (#"Sprožilec za izmet 2"). This trigger should hold its value until the post-eject sensor detects the ejected box leaving the main conveyor: #"Sprožilec za izmet 2" := #"Sprožilec za izmet 2" AND NOT #"Senzor izvržene škatle 2".
When a box is ejected at eject station 2, this trigger bit will reset once the box reaches the ejected box sensor 2. Develop a logic that iterates through the 30 elements of box data (#"Podatke Škatle) to identify the eject position (."Pozicija za izmet") of the box with the highest actual position (."Dejanska Pozicija") below 150. This identified position will be labeled as "Highest eject position 2" (#"Najvišji položaj za izmet 2"). Initialize #"Najvišji položaj za izmet 2" to 0 before the loop to handle cases where no boxes are positioned before eject station 2 at 150cm.
Aggregate all this information to determine a TRUE or FALSE value for #"Izmet 2" as follows: #"Izmet 2" := #"Sprožilec za izmet 2" OR (#"Izmet 2" AND (#"Najvišji položaj za izmet 2" < 150).
In summary, maintain the value of eject trigger 2 as 1 until the box ejected at eject 2 triggers the post-eject sensor. Keep eject 2 (#"Izmet 2"), the actual ejection mechanism, at a value of 1 (TRUE) under the condition that the recently ejected box at eject station 2 has not yet reached the ejected box sensor 2, or the next box arriving at eject station 2 will not surpass eject station 2. This approach aligns with the existing process model to address the query at hand.
In order to deactivate the Thrower (Izmetalo), it is recommended to set up two conditions. Here are the specific instructions for Eject 2 (Izmet 2 at 150cm): First, convert the #"Box data"[#d]."Ejection position" = 150 (#"Podatki Skatla"[#d]."Pozicija za izmet" = 150) conditional one-shot to a Boolean bit named Eject trigger 2 (#"Sprožilec za izmet 2"). Keep the trigger value latched until the post-eject sensor detects the sorted box leaving the conveyor.
Next, create logic to iterate over the 30 elements of box data (#"Podatke Škatle). When the eject station output (#"Izmet 2") value is 1, determine the eject position (."Pozicija za izmet") of the box with the highest actual position (."Dejanska Pozicija") below 150. This value will be named "Highest eject position 2" (#"Najvišji položaj za izmet 2"). Make sure to initialize #"Najvišji položaj za izmet 2" to 0 before the loop starts.
Finally, combine these steps to assign either a TRUE or FALSE value to #"Izmet 2" using the following code: #"Izmet 2" := #"Sprožilec za izmet 2" OR (#"Izmet 2" AND (#"Najvišji položaj za izmet 2" < 150); This means that Eject 2 will remain active until the ejected box reaches the sensor and the next box is not going beyond the eject station. This process should address the issue raised in the original post efficiently.