Hi steurung__,

what Jacek - with his rough words - wanted to say is, that you should take care about how a program is executed.

In you case the use of a FOR loop is the wrong solution. At the end of the loop, your index will always be 5. Since other program code is executed after or before your code, no program is able to react on the values written prior. Only the last values (#i = 5) can be further used.

You can try it without the FOR loop and write #i += 1; after the CASE loop. And do some additional programming to initalize #i.

Kind regards
Stefan

Attached is a way to get closer to the solution you seek.  Note the slight modification at the top and bottom of your existing code. It assumes your case state handling is correct.  You may want to read the various comm block output parameter details from F1-Help to know how long each output is held in that state to give you a feel for when and how to use them.

If you want to continue using PLCs, you may want to read on a little more and put your "I'm not going to be offended because someone is trying to help me."

I'm going to make some assumptions.  Tell me how close I get (if you like):

1. You were taught PC (not PLC) programming and ended up getting a job programming PLCs instead of PCs

2. You are relatively new to PLC programming, especially with Siemens and structured text (SCL in Siemens language)

3. You are relatively experienced with PC programming - which might have somewhat jaded your thinking about how computational and similar problems are handled

4. You have not programmed a µController before (Arduino, AVR, PIC, ESP32/ESP8266, or similar), so are unfamiliar with how their typical setup works (which is very much like how PLCs work - in the background:

{Fake C pseudo code for structure of typical µController high level language with the Siemen PLC logic injected at appropriate places}

//For Siemens PLCs, this is the hardware configuration of a TIA Portal project
#DEFINE HARDWARE_ID_MAIN_PLC    16#0310;   
#DEFINE HARDWARE_ID_MAIN_PLC_PN 16#0064;   
#DEFINE HARDWARE_ID_MAIN_PLC_PN_PORT_1 16#0065;
#DEFINE HARDWARE_ID_MAIN_PLC_PN_PORT_2 16#0066;

void setup()
{
  OB100_Startup_OB
}

void loop()
{
  // Cyclic Logic that gets called over and over again
  OB1_MAIN;
  OB200_SUBSYSTEM_1;
  OB201_SUBSYSTEM_2;
}

void main()
{
  while (TRUE)
  {
    loop();
  }
}

Now, with that in mind, what happens when logic requiring multiple PLC scans (loop iterations) to complete are stuffed into a FOR loop? They never complete during that extremely short time period (sub-msec).  After a few main loop (PLC scan) iterations, eventually the first request made the first time eventually completes for the value of FOR loop index of 0.

If you already knew all this, then I'm confused by your getting offended when someone suggests your understanding of how the very hardware you are attempting to control acts contrary to your expectations.

Keep an open mind and realize we are not intending to offend, but to jolt you into a different way of thinking in whatever way seems appropriate.  If someone comes in with a particular paradigm in mind and leaves with the same wrong paradigm feeling all offended, they are in the wrong profession / job.

steurung__

Hello,

I attempt to read five different registers from a variable frequency drive. The communication criteria is not an issue here, where I can read any destined address via a tag of Word type labelled as DATA_ADDR.

//FOR #i := 0 TO 5 BY 1 DO
IF #INIT THEN
  #i += 1;
ELSE
  #i := 0;
  #INIT := TRUE;
END_IF;

IF #i > 5 THEN
  #i := 0;
END_IF;

CASE #i OF

  0:

    #DATA_ADDR := 0;

    #ETA := #DATA_PTR_Receive;

    #"Ready to switch on" := #ETA.%X0;

    #"Switched on" := #ETA.%X1;

    #"Operation enabled" := #ETA.%X2;

    #"Fault detection" := #ETA.%X3;

    #"Voltage enabled" := #ETA.%X4;

    #"Quick stop" := #ETA.%X5;

    #"Switched on disabled" := #ETA.%X6;

    #Warning := #ETA.%X7;

    #Reserved := #ETA.%X8;

    #"Command via fieldbus" := #ETA.%X9;

    #"Target reference reached" := #ETA.%X10;

    #"Internal limit active" := #ETA.%X11;

    #Reserved_1 := #ETA.%X12;

    #Reserved_2 := #ETA.%X13;

    #"Stop key active" := #ETA.%X14;

    #"Reverse direction" := #ETA.%X15;

  1:

    #DATA_ADDR := 1;

    #"Motor speed" := #DATA_PTR_Receive;

  2:

    #DATA_ADDR := 2;

    #R1 := #DATA_PTR_Receive;

  3:

    #DATA_ADDR := 3;

    #AI1 := #DATA_PTR_Receive;

  4:

    #DATA_ADDR := 4;

    #AI2 := #DATA_PTR_Receive;

  5:

    #DATA_ADDR := 5;

    #AI3 := #DATA_PTR_Receive;

END_CASE;

//END_FOR;

...

Any SCL solutions please?

steurung__

0_Einstein

Attached is a way to get closer to the solution you seek.  Note the slight modification at the top and bottom of your existing code. It assumes your case state handling is correct.  You may want to read the various comm block output parameter details from F1-Help to know how long each output is held in that state to give you a feel for when and how to use them.

If you want to continue using PLCs, you may want to read on a little more and put your "I'm not going to be offended because someone is trying to help me."

I'm going to make some assumptions.  Tell me how close I get (if you like):

1. You were taught PC (not PLC) programming and ended up getting a job programming PLCs instead of PCs

2. You are relatively new to PLC programming, especially with Siemens and structured text (SCL in Siemens language)

3. You are relatively experienced with PC programming - which might have somewhat jaded your thinking about how computational and similar problems are handled

4. You have not programmed a µController before (Arduino, AVR, PIC, ESP32/ESP8266, or similar), so are unfamiliar with how their typical setup works (which is very much like how PLCs work - in the background:
...

Hi,

Thank you for such a great elaboration. Based on your request, below are the answers for your queries:

1. True
2. True
3. True
4. False: I have programmed previously Arduino UNO and PIC18F450 (using assembly and a high-level simulator called PIC18 Simulator IDE).

Based on 4. I can tell (correct me if I'm wrong) that a uC code block, executes syntax-wise via a syntax pointer. For example, assume that the letters from a to c represent command syntax (of whatever function):

a. syntax 1
b. syntax 2
c. syntax 3

The pointer cyclically moves from a to b to c when the code is put under execution.

For your modified code, I would like to give my appreciations for your efforts. I have tried it and it basically gives the same results of my latest reply to Stefan: The DATA_ADDR actually increment from 0 to 5 then shutdown to zero as a restart. I can visualize this in TIA, under the DATA_ADDR register in the MB_Client function block.

The problem is that, the client declares a "8200" STATUS, which reflects that the reading process is toooo fast for it to maintain. The registers as a result concatinate.

How about to add to this new code a TON for each CASE such that:

1. at the beginning of each CASE, a TON is initialized, e.g., for CASE 0 a TON_0 (which is a TON_TIME) static variable in the FB, has its IN set to true. Case 0 is only initiated as long as the bit Q of TON_0 is TRUE.

2. the succeeding CASE, e.g., CASE 1 is only initiated if TON_0.Q (and all other TON_x with x!=1 are FALSE).

3. in the control condition where checking if #i>5 we reset all timers and hence we obtain the same results of your posted code, added to a Delay in each case, to stress the MB_Client less and obtain more stable outputs.

I would like to hear your comments if possible please

The key to my prior reply was how the PLC scans - and I stated I assumed your logic for handling the comms was correct (even though I knew it was not correct from a quick glance - at least for a PLC).  I wanted to address 1 thing at a time.  Now that your programming paradigm is able to shift, is shifting, is almost there even, let's talk about how comms work on Siemens S7 PLCs - in general.

(FYI, everything I'm saying is in these forums as well as all coded applications examples provided by Siemens available for free download from this web site, including Siemens provided libraries for integration into your own projects)

In general:

During PLC startup or during an event (logic state change, usually leading edge detection used to signify such an event, like power is now applied to a remote device, some time has passed and the device should be available for communications) logic is written to configure / establish initial communications. 

SEND and RECEIVE comm block requests are not allowed until the initial communications has been successfully established, so you have to look at the outputs and handle any ERROR and DONE outputs to save the state across the entire PLC program for that connection path (ID).

For SEND, a SEND comm block is used and triggers to REQUEST data to be sent (be it a routine remote data request or just pushing data like to a SQL server system),.

THEN PLC logic (absolutely must be) is waiting for the send request to complete before attempting to send again.  It usually takes multiple PLC scans - especially at the lower PLC performance levels in the s7-1500 family.  The SEND block outputs must be monitored for DONE or ERROR.  Some errors are predictable and can be automatically handled, whereas some are strictly useful during initial development where configuring of send block parameters is done.  Once the DONE happens, it's true for ONE scan, so you gotta look for it and use it to possibly request another SEND.

RECEIVE is often just turned on, and the outputs of the RCV blocks are monitored for ERROR or new data received (and sometimes the length of the received data).

It is also important for shared networks not to flood it with requests.  Siemens created a library for automatically managing this type of thing on Profinet networks where high speed performance is required.

Hopefully this can get your first request working.

In other words, punt your current coding efforts (for a little while), and get just one request working until you understand all the nuances required to successfully configure, request, and receive data from a remote device.

Once you get one working, you can then wrap all that into a finite state machine (FSM) that manages all your comms so you don't flood the infrastructure with requests.