Cognex 5401 camera hangs up occasionally

[RMA 0]

I've got a situation where some (but not all) Cognex 5401 cameras are hanging up and the only way to get them 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 via Ethernet-IP from Siemens 300 Series PLCs via a CP343, not via the H/W digital in- and outputs. Firmware is 3.30.03 (406) for two cameras which hang and 3.20.00 (214) for another camera which does not fail, however it also has a much simpler program - 117 cells vs. ~550. 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 as acknowledgement. Under some circumstances some of the cameras will hang up after sending the "1" to acknowledge the Trigger command. Under these circumstances in the send & receive buffers of the camera DB I can see the GR command in the send buffer (and I assume it will be sent), but if I modify the program so that before I send the GR command, I clear the receive buffer (fill it with "0"s) before sending the GR command, no acknowledge comes back. This seems to happen on cameras having the more complex programs and may have something to do with "#ERR" propagation - we can force the fault reliably on one camera by simply leaving out a Hall sensor, who's orientation gets checked. Has anybody any ideas as to what's going on here? Thanks in advance Roy PS Are there any good online (free!) sources of good indepth descriptions of how the cameras function. I've a feeling that half the problem may be that nobody, including me(!), has much real idea about how everything really works. All I've got to go on are the Help Files, there are no handbooks available from the customer. Edited 16 Aug 2007 by RMA

[Bob O 8]

Roy, I just thought of this so you may also try enrolling in the Cognex smartlist here.. http://www.cognexsensors.com/support/Smart...php?skin=Cognex I have yused the DVT smartlist with good results. Hope this helps

[RMA 0]

Thanks Bob, I'll try that as well, but at present (on site) I don't have e-mail access. Cheers Roy

[Chris Elston 79]

I've never had much luck with "network" triggering. I've always where possible hard wired the trigger to the camera then send the rest of the data out of the camera via ethernet. This seems to be the best setup for me. Of course hind sight now for you... Sound like the camera is setup for Native Mode commands, hence the ascii strings to command the camera to trigger and such. Which way is the trigger going? A sensor on the line triggers the PLC, then the PLC sends a native mode command via ASCII to the camera via ethernet? Or does the camera see something, then it triggers itself, then sends the data to the PLC? One thing on the ERR, they will mess you up. If in one case, let's say a normal case, you get a vaild "1" sent to the PLC for your hand shake, then if something is causing that same cell to go into a ERR state, you've got some problems. The ERR won't sent anything to the PLC. Either state. What you've got to do is either fix what is causing the ERR, or if it's some situation that always causes an ERR, you should use a function called ERRFREE( ), If your not having problems with the ERR cells, then I am not sure I would know what is happening for sure. An example of how to use an ERRFREE would be let's say your data that is a "1" going to your PLC is in cell B6. And something happens and causes B6 to show ERR instead of "1". I would cut and paste B6 to say B7. Then in B6, insert an ERRFREE ( ) that is pointing to B7. Next time you get a ERR in what was B6, but you moved it to B7, B7 will show ERR, but B6 will be a "0". Atleast it's a value instead of nothing... Careful when you move cells around, B6 could be absolute referenced or relative. There will be another function somewhere grabbing the data in B6, and blasting it onward to your PLC.

[RMA 0]

Everything is controlled from the PLC. When a part is in place, the PLC starts the sequence by sending the Type command, followed by the Trigger command and finally the "GR" Get Result command. This is controlled by a small SFC in the FC responsible for handling the camera. After each command is set the program waits for the "New Data available" signal from the CP343 handler, checks that the acknowledgement ="1" and if so, increments to the next Step in the SFC. When we have our fault condition everything goes OK up to the Trigger, which is successfully executed (we can see the new picture on the monitor PC for the Cognex cameras). The acknowledge "1" is sent back to the PLC and the "GR" command is sent to the camera. On the monitor PC we can see it in cell A7, however, neither an acknowledgment nor the required data String, is sent back to the PLC. (Following receipt of the Trigger acknowledge, I modified the programm to write a series of "0"s (binary, not ASCII) in the receive buffer, and they do not get overwritten with text. Edited 17 Aug 2007 by RMA

[RMA 0]

Problem solved! The problem turned out to be in some cells containing the values measured by some blob() commands, which are also sent to the PLC. Unlike the main result which was converted to a String before being placed in a cell for the writedata() command, these measured values were being simply copied to the cell with the errfree() command, e.g. errfree($B$224+1). Under normal circumstances the contents of the cell would be something like "283.456" and apparently the writedata() command can recognise this as a Real number and converts it automatically to a String. However, in the case of an error, the cell would contain simply "1". We changed the errfree() command to errfree($B$224+111.111) and that solved the problem. I would assume that we could have left the original contents of the cell as they were and then copied the data to another cell for the writedata() command using the stringf() command to force it to String format, but that would have been more effort! Thanks for the help anyway. Cheers Roy Edited 17 Aug 2007 by RMA

[Chris Elston 79]

Glad to hear it. I've got some examples of blob programs in the downloads, those are cases too where I used ERRFREE to fix some blob tools that did not see an image at certain times. http://forums.mrplc.com/index.php?dlcategory=42