RMA

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

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.

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

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.

Unless they exist in 400 series CPUs, which I've never used, OB2 - OB9 don't exist, not on my copy of Step7 V5.3, anyway. You'll find the IEC Timers in the Standard Library. You can access this from the Simatic manger via: File -> Open then Libraries -> Standard Library For reasons best know to Siemens, the Timers are not in the IEC Functions sub-directory, but in System Function Blocks! SFB3 - SFB5 are what you're looking for. You can use them directly in LAD OK.

You can do this using the SFCs 82, 83 & 84. You'll find them in the System Function Blocks folder of the Standard Library.

1) Your memory addresses take the form M0.0 for BOOLS (Bits), MW0 for WORDs or INTs and MD0 for DWORDs or DINTs. 2) You can't use Bits at a memory address that you also use for storing WORDs or DWORDs, the last one to be written in the cycle will overwrite what previously there. For example Bits M0.0 to M0.7 occupy Byte 0, if you write an INT to MW0 this will overwrite Bits M0.0 thru M1.7, writing a DWORD would overwrite Bytes MB0 thru MB3, which also happen to be WORDs MW0 (MB0+MB1) and MW2 (MB2+MB3). Finally M-memory is global, that is the same memory areas can be accessed from all blocks, so you can't use M0 for different purposes in different networks. 3) You can use Timers in FBs and FCs OK, you need to note that the initial value must be in S5TIME format. (See the help files for examples.) 4) Once you've handled the error in OB80 (or any of the other interrupt OBs) OB1 will automatically continue where it left off in the cycle. By the way, you don't have to program OB80 if you don't want to. If all you need is to avoid the CPU going into STOP, all you need to do is have OB80 (etc.) present - you can leave it empty.

I think the real answer is that this is another of those poorly phrased questions, of which we, unfortunately, see far too many! The answer may indeed be one word (line) of program command, but as Gerry mentioned, that is likely to translate to a lot more words of memory which get used.

I'm afraid I don't know anything at all about AB PLCs, but according to the help-file WinCC supports the following AB models: SLC500 to SLC505, MicroLogix and PLC5 models 5/11, 5/20, 5/30, 5/40, 5/60 and 5/80. Depending on model communication can be via DF1 point-to-point or multi-point via KF2 or KF3 modules and DH485 point-to-point (RS232) or multi-point (RS485).

The current generation of Siemens MMCs is very unreliable. If you haven't got an external Prommer, then your only choice is to send it back to Siemens for "repair". Yes, they do actually repair them, because it's a formatting problem. As far as I'm aware, they don't charge for this service, at least they don't in Germany.

There is a mathematical method for handling this problem, but unfortunately I can't remember what it was called. I started my working life designing first generation computer controlled telephone exchanges 40 years ago. We were initially working with DTL (diode-transistor-logic) before moving on to the now ubiquitous TTL circuits, but even they had (by modern standards) relatively slow switching speeds, which meant that the Karnaugh map alone was not sufficient to describe the logic accurately. Maybe this will jog somebody else's memory and they might remember what the method is called.

There is a known problem with the current series of MMCs - those with 8Lx11 in the part number. The problem is solved with Step7 V5.3. If you have Step7 V5.2 there is a Hotfix available on the Siemens website here.

I've never used the MCR function so I may be wrong (probably?), but I have the impression that if you are using lots of MCR groups you use the MCRA / MCRD commands to divide them into convenient subgroups. For example you might have ten MCR areas in your program of which, say, the first four are for job A and the last six, then you would group the first four in one MCRA / MCRD area and the following six MCRs in another. I may be totally wrong and if I am, no doubt someone will be sure to point it out, but it just seems a fairly logical useage. Guest is right that the MCR command does not jump over a portion of the program, but while Set and Reset commands are no longer executed, they are left in the state they are in, not set back to 0.

I'm not sure if it's what Snerkel's refering to or not, but there is a problem with PLCSIM if you use its record/playback facility. The problem arises because PLCSIM stores each step of the program Bytewise, not Bitwise. This means that if you want to pre-record one part of your program to play it back while manually simulating another part, to check for correct / incorrect interaction, the part of the program must not write to any I/O which is in an I/O-Byte which is part of the pre-recorded program. If it does, when you manually write a value to the I/O it will get overwritten by the pre-recorded value on the next step of the playback. It's a pity they had to spoil a potentially very useful feature by being too cheapscate to do the job properly.

Yes, you need the ProTool Pro CS S/W to actually modify the program. Other than the normal licence you get when you buy any PC S/W, there is no further licensing required for CS. You don't have an authorisation diskette, for example.