Trigger by encoder suggestions

Peter Nachtwey said:
BTW
Code: 
      if armed then
            if counts >= trigger_counts then
                  trigger := true;
                  armed := false
      else
           trigger := false;
           if count < trigger_counts then
                 armed := true;
      end_if
This method makes sure the trigger is set only once per revolution. I don't see the need for check for counts over 100 when they are reset by the z pulse so the range of counts is 0-99.
Click to expand...


Thanks Peter, I didn't realize the term was so common; I thought he had specific meaning (of course he may anyways).


I agree to both your point in the code snippets, specially testing for equal :)=) count is very likely to miss.
 
Hi guys, sorry for not responding all this time. Some private things came in between and after that I started a different project.

BryanG said:
I checked the manual and the CP2E does have High Speed Counters
https://assets.omron.eu/downloads/manual/en/v5/w614_cp2e_software_users_manual_en.pdf
Section 10 covers Interrupts, section 11 cover High Speed Counters



There is a tutorial on setting up a High Speed Counter:
https://www.youtube.com/watch?v=jWGlXCa7DLs


I haven't used the CP2E or CX Programmer so I can only speak in general terms. A High Speed Counter (HSC) works outside of the normal program loop, so it can count inputs a lot more quickly than a normal counter, it is designed for use with Encoders. Once the HSC reaches a Set Point it calls an Interrupt. An Interrupt is exactly how it sounds, it interrupts the normal program loop, runs some software and then returns control to the main loop. I don't know if the CP2E allows you to alter the HSC target value whilst the program is running. But for a Siemens PLC I would set up a HSC, it would reach its Set Point, Interrupt the main program loop and pass control to an Interrupt sub routine. In the Interrupt routine I would tell the camera to operate, calculate the new Set Point for the HSC, transfer the new Set Point and Reset the Current Value. Then return control to the main loop.


Using a software system you will always be limited by the speed of your main program loop. At a camera trigger value you would store the current value, add the number of counts for the next triggering point which would give you the next target value. Yes it can be a problem if you go beyond the counters maximum value, but in a real world situation it isn't usually too much of an issue. If you use an unsigned 32 bit Integer value it has a maximum value of 2,147,483,647. If your process triggered with a 100 count every second that would still be 357,913 minutes before you hit maximum, or 248 hours, or 10 days. So you just need to make sure that you reset the system before that happens, often a factory gets powered down at the weekends, which would solve it for you, otherwise you just need to catch it a trigger point.


You don't have to use the Z input to reset the counter, you can reset the counter at your trigger point through software. I would use the Z input with another interrupt so that you can check that the counter is counting correctly.


The Z channel doesn't have to be used to Zero a count:
https://www.usdigital.com/news/post...MIwI3gjtiC7wIVkt_tCh3xsQeFEAAYASAAEgLdyvD_BwE
Click to expand...

I'm going to try this. I always assumed that problems would occur when the counter adress would overflow but that's indeed unlikely to ever happen.

Thanks everyone for all the info and suggestions! Hope I can proceed this topic if I run into more problems regarding the subject.

Regards,
Andy
 
andepand said:
Hi guys, sorry for not responding all this time. Some private things came in between and after that I started a different project.



I'm going to try this. I always assumed that problems would occur when the counter adress would overflow but that's indeed unlikely to ever happen.

Thanks everyone for all the info and suggestions! Hope I can proceed this topic if I run into more problems regarding the subject.

Regards,
Andy
Click to expand...


I would plan for a rollover rather than rely on no overflow.
The manual describes a counter setting for "Circular (Ring)" Mode. I would use that and validate/adjust my "Target_Count" to account for rollover.
 
kalabdel said:
I'm curious what you meant by that, how do you implement it?
Click to expand...

Good question. I haven't had much use for interrupts before so I'm kind of new to it.
Can an interrupt be triggered internally or only by a hardware input?

Second, I still want to use the Z pulse for keeping my counter in sync, any suggestions how to program this?

Regards,
Andy
 
You will need to read the manual to figure out the answers as it differ for each platform.

In your case the program should generate an interrupt when current count equals the count value you loaded for comparison; somewhere. The manual and youtube could be great help to you.

I believe Bryan thinking is to use the Z pulse to generate a hardware interrupt where you would put in code to verify that the counter is doing what it is supposed to do; which I'm not clear on.

The Z interrupt would be configured somewhere in hardware configuration and there would probably be option for rising or falling edge.


Edit: With regard to your question regarding triggering an interrupt "internally", that is again platform dependent, Siemens > No, Codesys > I think Yes, they allow for software generated interrupt.
 
I would use the CTBL function in the PLC.
See attached document for explanation of motion instruction Evan though written fro CJ1M they apply to CP1L.
 
The main problem still is that my set trigger value could be too close to the maximum value of my (ring) pulse counter. I.e; pulse counter is reset > 1000 (every cycle) but the operator sets the trigger position at pulse 2 or pulse 999.
This is easily missed due to the characteristic of the plc's scan.

As earlier suggested by BryanG, I should just let the counter count in a lineair matter without resetting it every machine cycle.

I'm still working out the following so perhaps someone can throw me some suggestions; the encoders position is linked to the machine's position. If I don't use a Z pulse or input from some other cycle operated sensor to reset the counter, then how do I make sure I'm staying in sync?

I would need some sort of correction linked to a mechanical part of the machine.

I'm sure this is something very comon so instead of writing some unwieldy piece of code, perhaps there are better ways?
 
Please explain a bit more how the system works. What is moving and what you mean by trigger.


An example would be, a conveyor moving at constant speed (assume it is constant for the sake of clarity) and a product is placed on it. A stationary camera will take a picture of the product when it enters it's zone. In this case a trigger, say a photo eye, us stationed at the position where the product enters the conveyor and the distance between the sensor and the product is known, in some sort of engineering value. The encoder is connected to the conveyor drive, again just accept that for now, and also assume no slippage.

When the sensor is "triggered" by the product passing, the program grabs the current counter value, whatever it is and adds the distance from the sensor to the camera and that will the count value at which the camera is activated.
Use that example and modify it to describe your scenario. If the camera is moving and product is stationary or any other way.


I don't believe Bryan meant linear but rather contineous , which could be linear or circular. The latter would work better, in my view.
 
kalabdel said:
Please explain a bit more how the system works. What is moving and what you mean by trigger.


An example would be, a conveyor moving at constant speed (assume it is constant for the sake of clarity) and a product is placed on it. A stationary camera will take a picture of the product when it enters it's zone. In this case a trigger, say a photo eye, us stationed at the position where the product enters the conveyor and the distance between the sensor and the product is known, in some sort of engineering value. The encoder is connected to the conveyor drive, again just accept that for now, and also assume no slippage.

When the sensor is "triggered" by the product passing, the program grabs the current counter value, whatever it is and adds the distance from the sensor to the camera and that will the count value at which the camera is activated.
Use that example and modify it to describe your scenario. If the camera is moving and product is stationary or any other way.


I don't believe Bryan meant linear but rather contineous , which could be linear or circular. The latter would work better, in my view.
Click to expand...

Here goes.

The PLC triggers a Vision system which reads data from a 2D code.
Products containing this 2D code are moved pass the camera by a transport chain and are spaced 20 inch. this is an ongoing process. ​

The encoder turns one revolution in one machine cycle, or 20 inch.

Different product batches contain a different layout, so the 2D code's position on the product differs from one product to another.
The camera is placed in a fixed position so the camera trigger moment (to take a photo and get the data contained in the 2D code) within this 20 inch cycle changes per production run.

During setting up, the operator manualy turns the machine untill the code is positioned under the camera, then presses the "set trigger button" to write the current pulse counter value to a variable which later will be compared to the pulse counter during production.

As a result the vision system will photograph every passing 2D code.

Hope this gives you an idea

EDIT:
Up to 4 camera's may be used in different places above the machine so 4 different camera triggers could be used within one machine cycle.
 
Last edited:
andepand said:
I'm sure this is something very comon so instead of writing some unwieldy piece of code, perhaps there are better ways?
Click to expand...


Do you consider this unwieldy:

Code: 
[COLOR=Blue][B](* Assumes HS_cntrPV will always be in the range [0:999] *)[/B][/COLOR]
[COLOR=Blue][B](* Assumes trigger_val is the 1st of 10 contiguous INTs apropo the trigger *)[/B][/COLOR]

Trigger := (HS_cntrPV >= trigger_val && HS_cntrPV < (trigger_val+10))
           OR
           (HS_cntrPV < (trigger_val-990));
? It's not pretty to be sure, but it is as concise as it can be for what it needs to do.

EDIT:
If there are four different triggers, then we could put this algorithm into a function, and the main code could call it with
Trigger_0 = Trigger_n(posn := HS_cntrPV_0, tlow := trigger_val_0);
Trigger_1 = Trigger_n(posn := HS_cntrPV_0, tlow := trigger_val_2);
Trigger_2 = Trigger_n(posn := HS_cntrPV_0, tlow := trigger_val_2);
Trigger_3 = Trigger_n(posn := HS_cntrPV_0, tlow := trigger_val_3);
​
and the function would look like this
Code: 
FUNCTION Trigger_n : BOOL
  INPUT_VAR
    posn : INT;
    tlow : INT;
  END_VAR

  Trigger_n := (posn >= tlow && position < (tlow+10))
               OR
               (posn < (tlow + 990));

END_FUNCTION
Caveat: syntax errors are almost certainly present above.
 
Last edited:
There are a few ways to do this and I would like to have a better understanding of the numbers.

One "machine cycle" is equivalent to 20" of conveyor travel.
The encoder does exactly on revolution per 20"(machine cycle).
The encoder counts exactly 100 pulses per revolution (this I am not sure of)
10 pulses are slow enough for the 8ms scan (0.8 pulse per ms) cycle but 2 are too fast.

If we figure a conservative 0.4 pulse per ms that would come out to 250 ms per revolution or 250ms per 20" or 0.08 inches per millisecond or 6.6 foot per second.

Could someone please verify my math and understanding of the numbers shared.

Thanks
 
kalabdel said:
There are a few ways to do this and I would like to have a better understanding of the numbers.

One "machine cycle" is equivalent to 20" of conveyor travel.
The encoder does exactly on revolution per 20"(machine cycle).
The encoder counts exactly 100 pulses per revolution (this I am not sure of)
10 pulses are slow enough for the 8ms scan (0.8 pulse per ms) cycle but 2 are too fast.

If we figure a conservative 0.4 pulse per ms that would come out to 250 ms per revolution or 250ms per 20" or 0.08 inches per millisecond or 6.6 foot per second.

Could someone please verify my math and understanding of the numbers shared.

Thanks
Click to expand...

Well, I would say it's like this,

The encoder is a programmable one, set to a 1000 pulses per revolution with a fixed zero.
It turns exactly one revolution when the machine does one cycle and during this cycle the 'conveyor chain' moves exactly 20 inch.
It's a chain which acts as a conveyor belt but with evenly spaced pushers attached to it.
Each pusher transports a product which has been fed to it at the beginning of the conveyor.
You can really look at it as a standard factory conveyor transporting products, but guaranteed to be evenly spaced because of the pushers.

Anyway, my current scan time is 5 ms, some other code is doing other stuff while eating scan time.

This means that at an operating speed of 20000 products (or cycles) per hour, it's doing 20000000 pulses per hour.
Or 5556 pulses per second
Or 5,556 pulses per millisecond
So 27,8 pulses per scan.

I have to add that the camera trigger doesn't have to be accurate to a single encoder pulse. The vision system has a wide image and can look for the code in sort of a big area.
>20 pulses might become a problem though.
 
Last edited:
drbitboy said:
Do you consider this unwieldy:

Code: 
[COLOR=Blue][B](* Assumes HS_cntrPV will always be in the range [0:999] *)[/B][/COLOR]
[COLOR=Blue][B](* Assumes trigger_val is the 1st of 10 contiguous INTs apropo the trigger *)[/B][/COLOR]

Trigger := (HS_cntrPV >= trigger_val && HS_cntrPV < (trigger_val+10))
           OR
           (HS_cntrPV < (trigger_val-990));
? It's not pretty to be sure, but it is as concise as it can be for what it needs to do.

EDIT:
If there are four different triggers, then we could put this algorithm into a function, and the main code could call it with
Trigger_0 = Trigger_n(posn := HS_cntrPV_0, tlow := trigger_val_0);
Trigger_1 = Trigger_n(posn := HS_cntrPV_0, tlow := trigger_val_2);
Trigger_2 = Trigger_n(posn := HS_cntrPV_0, tlow := trigger_val_2);
Trigger_3 = Trigger_n(posn := HS_cntrPV_0, tlow := trigger_val_3);
​
and the function would look like this
Code: 
FUNCTION Trigger_n : BOOL
  INPUT_VAR
    posn : INT;
    tlow : INT;
  END_VAR

  Trigger_n := (posn >= tlow && position < (tlow+10))
               OR
               (posn < (tlow + 990));

END_FUNCTION
Caveat: syntax errors are almost certainly present above.
Click to expand...

Well, that's pretty much the working of my current code. If someone would tell me that this is how one who actually went to school for this stuff would do it, then I rest my case and will focus on optimizing what I have.

I'm just very eager to learn the optimal way of doing things.
 
20,000 cycles per hour, that's 20,000 of 20 inch moves?
Interesting.

You are very likely to have too much cumulative error with even 10% of that volume.

Set the encoder resolution to its highest, set it up for circular counting. On first configuration(operator pressing the button) grab the current counter value and add the goto value and that is your target/trigger count which you feed to HSC as reference/compare value.
The reference value= current count event will generate hardware interrupt in which you trigger the camera "and" grab the current count to setup the next position (in regular scan).

Verification and adjustment for rollover maybe done in regular scan and so is calculating the next position and loading it to HSC.
 

Similar Topics

J
Trigger camera off encoder counts in Rslogix 5000
I am running into some problems trying to trigger a camera to take a picture every 15 degrees when I spin the part I am looking at one full...
Replies
6
Views
3,613
Ken Roach
Ken Roach
J
One input X0 every time trigger different output alternatively Y0 and Y1
Hi i would like to ask! Im using Omron CP1E PLC May i know how to use one input to trigger two outputs alternatively? Meaning press X0 on, Y0...
Replies
11
Views
391
Ken Moore
Ken Moore
afm
Trigger a **** reboot from PLC
Hi all, I use e won for my OPCUA to back up my PLC (B&R X20 system) data. Whenever e won does maintenance updates, I need to reboot the e won in...
Replies
2
Views
467
James Mcquade
J
T
HMI error on runtime application when adding trigger
Hello ladies and gents I’ve hit a road block on a project, it’s AB for preface this is a converting line including Winder tailsealer and...
Replies
4
Views
763
Tmills407
T
A
Omron. PLC Clock to trigger output
Hi, I'm using CX Programmer and just seeing what the best way to trigger an output from the plc clock time would be. I need this to come on at 9am...
Replies
4
Views
1,729
BITS N BYTES
B
Back
Top Bottom