Timeout in NI-1772

[CDP_FPS]

I have set up a Smart Camera (NI-1772) in an grading system which is used to measure and count product fed passed the camera by a conveyor system. The prodcut is sized by length, (by the camera ) and a PLC  actuates mechanism that put the  product in the correct boxes, The PLC senses Discrete signals from the Smart Camera.  I have set the PLC to do the counting and the Camera read the counts registers via modbus, the counts are displayed using “Overlay  Function”  on a monitor connected to the VGA output of the Camera.

I have a through beam sensor, that is used as a trigger the camera to take images.

Everything is working great, almost all the time. But there are times, usually after the camera has been sitting idle for longer periods of time (usually 5 mins or more) that the camera seems slow to act on the first trigger signal,  and everything seems to be delayed as a result. (any triggers shortly after that seem to work fine) The screen is delayed being updated and the output to the PLC is delayed as well.

I’ thinking that this is a result of timeout in the trigger of the camera, which I have set to 5000ms. But im not sure about this.   

My logic is basically,

If triggered take an image -->measure objects --> if there is an object detected--> update discrete output--> read modbus registers & update screen-->end

If it timeouts--> read modbus registers & update screen -->end

Do you see any problems with this aspect of the logic, ideally once a timeout occurs I would have no code between the timeout and the end, but I had to come up with a way to update the screen, when there were no triggers.

How much delay would you think reading 7 modbus registers and updating the screen would take?

I can provide more information or code if required.

I appreciate any assistance you can provide.

[Greg-H]

Hi,

A couple of questions:

Have you tried setting the timeout for a different length of time, either higher or lower?  

If there are no triggers what are you updating on the screen?

The pseudocode you provided is on the camera,  what is going on on the PLC?

Regards,

Greg H.

[CDP_FPS]

Thanks for you reply.

I have tried the timeout really short, and I seemed to get more frequent problems,

and I have tried it really long and I seem to get less frequent problems. Although the problem is infrequent in general.

However, If the time out is really long, (based on the code I have) the screen doesn't update as fast, as the screen only updates when it times out.

The reason I wanted to update the screen is when there are no triggers is; I wanted to display all the relevant information on one screen (counts and image). 

I have 3 different sizes and 2 boxes for each size. So the camera sends the discrete signals to the PLC, the PLC waits the correct amount of time and moves the actuator to put it in the box. When one box is full (count =100) the PLC starts filling the other box(for that size). 

This way the conveyor doesn't have to stop when any one box is full. There are reset buttons (6 in total) that the operator presses once a full box has been replaced with an empty one, so the PLC knows that it can now fill that box.  If I let the camera do the counting, I would have to allow the camera to sense the reset signals from the operator.

So for simplicity and lack of I/O on the Camera I let the PLC do the counting and I send the counts back to the camera (soley to display on screen) via modbus signals.

I don't see any other way for the camera to read these modbus values and update the screen (other than following a trigger or timing out). I wouldn't have thought that reading 7 modbus registers and updating a screen would induce a long delay, but something seems to be. 

But I will try, for a test,  removing the code following a timeout so that the program executes a timeout as quickly as possible. And I will see if the problem goes away. 

Then I will know for sure the problem is a result of delay induced from code being executed following a time out.

If this is the problem;

I could install a PLC display to read the counts via modbus from the PLC, then there wouldnt need to be any code following a i timeout.  

but I would prefer to have everything on one display.

Thanks

Chris

[BlueCheese]

Hi Chris,

Does the delay happen every time it timeouts and the screen is updated (and you do a read via modbus)? Can you conclusively point to the modbus step as causing it? If you simply remove that function but keep the timeout and screen display does it fix the problem? If so then we could know for sure that is the problem. If that is it, it is hard to know what might be the issue with it being slow (a network trace might help here to see whcih side the delay is occuring on). You could possibly try changing the server/client relationship (so that all transactions originate from the PLC and occur in the background on the camera) and see if that helps. You could also try using a different protocol (like raw TCP or Ethernet/IP) that might have different timing characteristics (and again you could experiment with the client/server relationship and possibly try to use a mechanism that is asynchronous in the background).

Eric

[CDP_FPS]

Thanks Eric,

Its hard to tell if the delay is induced every time it times out. I assume it does, although the delay is only evident and problematic once in a while( I think, this happens because the camera will get triggered at random times and every once in a while the camera might get triggered immediately after a timeout, and IM thinking the camera processor is busy doing a modbus read, then updating the screen, before it can process the new image, inducing a delay) But I'm not sure about this.

I will try your suggestions they seem like they might help.

Thanks for your assistance.

Chris