Slightly OT - Cognex cameras

Does anyone out there know the ins and outs of Cognex cameras?

In particular, what happens if an event is initiated during the time while the cells are being updated as a result of a previous event.

We've got a situation where the camera is hanging up and the only way to get it going again is to switch the camera offline and then back online again from the monitoring PC - not exactly comfortable! We're driving the camera (model 5401, I believe) via Ethernet, not via the H/W digital in- and outputs.

I don't know who wrote the S/W (Cognex or the machine supplier) but it works on the basis of sending two letter commands (occasionally with further parameters, as necessary), e.g. "TR" = Trigger, i.e. get an image and process it and "GR" = get result - a text string. If the command is understood, a "1" (ASCII text) is sent back to the PLC.

According to the Sensor "Profile Job" task, the acknowledge is sent very early in the procedure and the "acquire image" command is taking about 100ms to execute. The program is so written, that as soon as the TR acknowledge is received then the GR is sent to the camera. This is likely to happen in way less than 100ms, hence the above question.

At the moment I've added a 100ms delay to the program which may or may not help (one other possibility is flakey H/W, since the camera is only a month or so old -early on the slope of the bathtub curve), but the question remains intersting from a theoretical point of view.

Problem solved!

Following a PM from Bob O I followed this post up on MrPLC.com and in the meantime I've found the answer.

For the benefit of anybody else who may have similar problems, here a quick summary:

The basic problem was that some measured values which we're transmitting back to the PLC weren't being converted to a STRING before being sent using the writedata() command. Under normal circumstances the cells would hold a value like, for example, "238.468". In order to stop problems with error propagation the data was being cleaned up using the errfree() command, so that in the cell was something along the lines of "errfree($B$244+1)". In the case of an error this resulted in a simple "1" in the cell and apparently, without the decimal point, the writedata command couldn't handle it. We changed the cell to "errfree($B$244+111.111)" and that solved the problem.

For more details, see the Thread here.