EirikV

Hi, Edit: Just to clarify the terminology used here: RLO is a status bit in the PLC that all bit testing instructions (A, O, AN, ON) write their resullt into. You can also manipulate the register from the user program using the SET and CLR instructions. ACCU1 (Accumulator Register 1) is a 32-bit data register in the PLC. The S7-300 series has two (ACCU1 and ACCU2), the S7-400 series has four. All logic and arithmetic instructions use these registers. You transfer data between these and the PLC memory with the L (load) and T (transfer) instructions. ACCU1-L is the lowest 16 bits of the ACCU1 register, ACCU-H is the highest. See my comments in the code below: OPN DB100 //Opens DB100 as a shared DB A DBX 12.0 //If bit 0 in byte 12 is high, then RLO = 1 OPN "INPUTS" //Open the "INPUTS" DB (RLO is not affected) = DBX [AR1,P#0.0] //Assign bit 0 - in the byte that AR1 points to, plus the offset in the pointer syntax (0 in this case) - equal to RLO OPN DB100 //Open DB100 again (it is only possible to have one shared DB open at a time) A DBX 12.1 //Test bit 1 in byte 12 OPN "INPUTS" //Open "INPUTS" DB again = DBX [AR1,P#0.1] //Assign bit 1 to value of RLO OPN DB100 A DBX 12.2 OPN "INPUTS" = DBX [AR1,P#0.2] OPN DB100 A DBX 12.3 OPN "INPUTS" = DBX [AR1,P#0.3] In other words, I think the original programmer knew what he was doing. If you wonder what the P#0.1 syntax is, it is a 32-bit pointer, where the three lowest bits indicate bit number and the remaining 29 indicate the byte offset. So P#0.1 means byte 0, bit 1. The DBX [AR1,P#0.1] syntax means take the base of the opened DB (offset 0), add the pointer in AR1 and add the pointer constant P#0.1 to it. DBX denotes that this is a bit operation (so it takes the 3 lowest bits of the pointer into consideration also), DBB is byte, DBW is word, etc. Operations other than bit operations does not care about the three lowest bits of the pointer. A prerequisite for this code to work is that Address Register 1 is loaded with some sane value, for example: LAR1 P#0.0 If you now do: OPN DB100 L DBW [AR1,P#0.0] You will load the word at DB100.DBW0 into ACCU1-L

You are correct. This is called a label. You can alter the program execution by means of the jump instructions (JC, JU, JN, JP, etc.) placing the program counter at the specified label. Example: A I 0.0 //Is this input on? JC foo //Yes, then jump down to the label "foo" //If not, we continue here O I 0.1 // If this input O I 0.2 // or this input is on BEC // end the block at this point //We end up here if either I0.0 is on or if neither I0.1 nor I0.2 is on foo: L W#16#F000 T MW100

Hi, I have a Lenze 9300 drive with a 2133 module mounted on it. As it is today, the set point is transferred to the drive while the release and direction signals are hardwired. Here is the code that controls the drive: L 0 //Steuerwort an Lenze T PQW 256 AN "M10.1" //--line on AN "M10.2" //--inching JC lade A "M10.2" //--inching JC tip A "M10.1" //--line on L 1 T PQW 258 //Steuerwort an Lenze AN "M40.1" //sence off rotation JC vorl L -1 L DB51.DBW 26 *I T PQW 260 //Schlaglängenfaktor an Lenze JU ende vorl: L DB51.DBW 26 T PQW 260 JU ende tip: AN "M40.1" //--sence off rotation JC vor L -100 T PQW 262 //Jogspeed an Lenze JU ende vor: L 100 T PQW 262 JU ende lade: L 0 T PQW 258 T PQW 260 T PQW 262 ende: NOP 0 What I want to do is to read parameters from the drive using SFC14 and 15. I looked at some example code that I found on Lenze's site (http://akb.lenze.de/akb-englisch/infopool.nsf/HTML/200413406) and made my own simple version. The problem is, I see in the hardware configuration of the example project that PAR(Cons.) + PZD( 3 W) is used, whereas in my project I cannot add this one because Step 7 complains about there not being enough room. I have attached a screenshot of my HW config. I did modify it and added a module called PZD (4W) which made me able to use SFC14 and 15 to read/write to it, but I get no reply from the drive when requesting a parameter. My code is as follows: AN #Enable R DB200.DBX 0.0 // Reset busy flag R DB200.DBX 0.1 // reset handshake flag and BEC // jump out if not enabled // Check if a transfer is in progress AN DB200.DBX 0.0 JC REQ CALL "DPRD_DAT" LADDR :=W#16#108 RET_VAL:=#retvals.ret_recieve RECORD :=#recieve_data // Check handshake and busy X DB200.DBX 0.1 X #recieve_data.sb_handshake A DB200.DBX 0.0 BEC A DB200.DBX 0.0 A #recieve_data.sb_error JC ERR JU FIN REQ: NOP 0 SET = #send_data.sb_read = #send_data.sb_handshake = #send_data.sb_length_1 = #send_data.sb_length_2 CLR = #send_data.sb_write = #send_data.sb_na = #send_data.sb_reserved = #send_data.sb_error // Calculate index. index = 24575 - Parameter number L 24575 L #Param_no -I T #send_data.index L #Sub T #send_data.subindex CALL "DPWR_DAT" LADDR :=W#16#108 RECORD :=#send_data RET_VAL:=#retvals.ret_send SET S DB200.DBX 0.0 // Set busy flag S DB200.DBX 0.1 // Set handshake flag BEU FIN: NOP 0 L #recieve_data.data T DB200.DBD 2 SET R DB200.DBX 0.0 // Reset busy R DB200.DBX 0.1 // Reset handshake bit BEU ERR: NOP 0 S #failed The send_data and recieve_data structures are 8 bytes long and are identical to the ones used in the example project. Does anyone know how I can get this to work without breaking the original code?

You can use FC105 for scaling. -Eirik

Because they are in German. ReparaturSchalterModul - RSM AbSchaltModul - ASM -Eirik

Upload the blocks and symbols file along with an explanation of what you want to do and I'll have a look. Edit: PM'd you my email Eirik

As a side note, if you have the STEP5 package and want to print out S5 programs and documents, you can use the S5Print utillity to print to a Windows printer. You just give it the @@@@@@LS.INI printer file (made with STEP5) and the Windows printer you want to use, and it will print the printer file for you, correctly formated.

Q1: This is indirect addressing. You load a pointer (denoted with the P# syntax) to a date and time variable (#DT1) into address register 1 (AR1), then year, month, day, hour, minute and second is extracted from it by taking the address AR1 is pointing to and picking out bytes with an offset given by the P#n.0 value (32-bit pointer). You can place the caret in STL view on an instruction and press F1 to get context sensitive help. LAR1 P##DT1 //Load pointer to #DT1 into AR1 L B [AR1,P#0.0] //Load the contents of AR1 + 0 bytes into ACCU1 in the size of bytes T #Year //Transfer to Year variable L B [AR1,P#1.0] //Load the contents of AR1 + 1 byte into ACCU1 in the size of bytes T #Month //Transfer to month variable Q2: Positive edge detection will only yield true when the signal you want to do edge detection on goes high. Positive RLO detection will look at the RLO bit and this does not necessarily go from 0 to 1 if an input signal does so, for instance: A I 0.0 //Here RLO goes from 0 to 1 if I0.0 goes from 0 to 1 AN I 0.0 //Here RLO goes from 0 to 1 if I0.0 goes from 1 to 0

Well, C/C++ gives you enough rope to hang yourself, but that is also what makes it so powerfull, at least for low level stuff. I don't know what it has to do with putting together a HMI application, though. I would go for using the .NET framework if you want to knock something together in a reasonable amount of time.

Hehe, no I'm not writing a history book :) It was more out of curiosity, I kind of have a fascination for these old, obsolete monoliths. Besides, there are lots of them in my area, so a little more knowledge about them could probalby be nice when I'm running around trying to figure out what went wrong! :)

Hi, I read on Wikipedia that there allegedly exists several third party programming environments for SIMATIC S5, even a C cross-compiler. Does anyone know where I can get my hands on this? Would be nice to experiment with!

Try using unsigned multiply instead. *U(422)

Sorry, I used the on-board RS-232 port on the PLC for that. Anyway, I have moved over to Modbus comms for this application, and it works quite good Thank you anyway for your time Eirik

Hi, I got it working instantly with RS-232C, so I guess that means the Host Link protocol is correctly implemented. I have now resorted to a EX9520 RS-232 to RS-485 converter connecting the panel(s) to the RS-485 end and the PLC to the RS-232 end. Still, I have problems. I can see on the diodes on the SCU that the panel is transmitting and the PLC is answering. On the Magelis panel though I can see in the event log that the driver reports ”PLC packet validation failed. Invalid checksum." and then "No reply from PLC within Timeout period." repeating itself down the log. I have tried with baud rates 19200, 9600, 4800 and 2400. No luck. My wiring looks like this: PLC.........Converter.........Panel 2-------------3 +D-------------D+ 3-------------2 -D-------------D- 9-------------5 4-+ 5-+ 7-+ 8-+ Eirik