LEQ Instruction Issues in Studio5000

[Brian10369]

I don't post here very often. Most of the time I can find the answer to my issues and/or question with some due diligence of searching. I just can't find anything in relation to a solution to my issue I am facing at this time.

I have a subroutine that I am sequencing based on different criteria.
I have a Air Differential Gauge that gives me a real value. I have to convert this value to a DINT based on the 6 decimal places and compare it to a setpoint.

A FANUC LR Mate grabs a part and puts it on the GAUGE, during the first measurement I and looking at 2 different real values and using a Low and High SetPoint to compare to.

For some ODD reason the first measurement value is below the setpoint by .007616. Yet this still puts a 1 into my DINT TAG that I am using for if it is a good part.

What is even more odd is after the first measurement the robot picks up the part, rotates J6 90 degrees and puts it back down. On this measurement it fails as it should.

I took 2 pictures showing that this is moving a 1 into a good value even though it is below setpoint.

I can't upload the pictures as work internet sucks. If I need to I can upload from home.

Anyone have any ideas?

 

[KuulKuum]

Without seeing your code, hmm. Your thread topic is "LEQ Instruction Issues in Studio5000"

For some ODD reason the first measurement value is below the setpoint by .007616. Yet this still puts a 1 into my DINT TAG that I am using for if it is a good part.

Depending on how you have the (LEQ) configured the first measurement could be Less Than the Setpoint and would evaluate as True...

 

[ASF]

In my experience, the built-in instructions like LEQ work 100% correctly, 100% of the time. With the small caveat that they work exactly as they were programmed, not necessarily exactly the way that the programmer intended.

The first thing I'd be suspecting is a scan sequence issue. Immediately before your LEQ (on the same rung/branch), MOV both operands into temporary tags of the same data types.

And of course some pictures will massively help the troubleshooting process.

 

[Brian10369]

I will upload from home tonight

I will upload the subroutine and pictures tonight from home.

Now that you mention it it very well could be a scan time issue

 

[Brian10369]

Here are 2 pics. I apologize I was looking at the wrong instruction. It is the GEQ not working. Still you can clearly see that the value is not greater than the setpoint, yet it still puts a 1 in the MOV.

I also uploaded the subroutine in PDF format

 

[Brian10369]

Another thought that I will try tomorrow at the machine. Instead of always looking for the values of a good part, I should look for the values of a bad part. Probably 85-90% of the parts will be good so, it will be less work to switch the process and look for only bad parts.

Thanks for any help in relation to why the GEQ is passing?

 

[dmroeder]

We're missing some information here, like how those values are populated. There is a rung order thing going on here. You are seeing the final value in those tags after the whole program is scanned, not the value at that point in the scan. See my attached screenshot.

 

[ASF]

Two things I'd be looking for.

The first is a scan sequence issue, as noted in my post #3 and illustrated by dmroeder above. Note - this is not a scan time problem, it's a scan sequence issue - i.e. the issue is in the order in which your logic is arranged and scanned. You can test to see if this is your issue using the technique I described in my post #3.

The second is the other logic relating to the LOWER0_LOW_GOOD tag. Remember, a MOV is not like an OTE. With an OTE, if the instructions before it evaluate to true, the tag assigned to the OTE is set to 1, while if the instructions before it evaluate to false, the tag assigned to the OTE is set to 0. A MOV, on the other hand, only does something if the instructions before it evaluate to true, otherwise it does nothing. In your case, if the GEQ evaluates false, LOWER0_LOW_GOOD is not set to zero, it's left at whatever its current value is, which may well be 1. We can't see what's before the GEQ instruction on the branch and the PDF is too broken up to read properly, but perhaps the rung preceding the GEQ is going true earlier than you expect, while the value is still above the specified threshold. By the time you look at it and take a screenshot, the value has dropped below the GEQ threhold, but it doesn't matter, the MOV has already set the tag to 1. Or perhaps the tag isn't getting correctly reset to zero between tests. Or perhaps something else is setting the tag to 1. There are lots of possibilities.

 

[Brian10369]

That does make sense. I was telling my boss that it seemed to be more of a timing concern.

So, I do get it and I will try a few things tomorrow and will post the results.

I think I know a better way to control the sequence along with the timing.

Thank you all for the suggestions

 

[Brian10369]

I did get the problem resolved. Thanks for the help

I ended up making another sequence to MOV the value I needed to compare to into a new sequence on the previous rung.

Then I can do the set point comparisons on the current rung.

Now that I got this fixed another problem arises.

I am storing a real value into a FIFO and it was working by placing the value into the FIFO when the sequence got to a certain spot. I used a one shot to verify I only capture it once per sequence.

Now it is filling up the FIFO on 1 sequence scan. I tried using the FIFO enable bit to try to trigger it just once.

I think I am doing too much within the sequence and it is populating it completely.

I’m going to try seoerating some of the math and see if that works.

 

[joseph_e2]

Check how you're handling the EN bit in the FFL instruction's control tag. An FFL instruction will execute once per 0-to-1 transition of the logic state feeding it...but RESetting the EN bit will cause it to "forget" that it already executed. When the scan comes around to the FFL instruction again, it sees that the EN bit is zero but the rung input conditions are 1 so it re-executes.

IOW, make sure the EN bit of the control tag assigned to the FFL instruction only goes true once per sequence.