Twincat FOR LOOPS

[PlayerByNature]

This is realy crazy:
http://infosys.beckhoff.com/index_en.htm

9600 baud is not guaranteed. All depends on the cycle task time from the serial control line.

Uhm. If i set a separate fast task for my serial control like, 1ms, I can't get this synchronized with my data packet placement in my main task.

Cause after each full packet it need to be send direct to the boatloader.

What u think guys?

 

[TurpoUrpo]

You cant link straight to documents on beckhoff by copying the address from address bar.

The one manual I looked that described use of com port functionblock library. Had it like this : there was one function block witch handled data with port controller hw, it did not say does it do it trough windows driver or not, but it does not matter. That same block made receive and send buffers, witch on other hand were used trough send and receive blocks from userprogram.

That SerialLineControl fb needed to be in fast program. Those send and receive blocks then read from the SerialLineControl fbs read and send buffers. Serial line control handles the communication itself.

Are those the blocks you are trying to use?

 

[PlayerByNature]

Turpo -> U mean 'PcComControl' that handles the data transfer between Serial Line Control and the hardware.

Could it be that Twincat communicates straight to the hardware? Or have to go by the CE driver?

Someone knows how i get the 2 tasks synchronized? The fast Task with Serial Line Control and the one that fills the packages. Cause other I get unpredictable coms of packages.

 

[TurpoUrpo]

SerialLineControl block is in newest version of that library, and it says it supercedes old hw depended blocks (like PcComControl).

you dont need to sync the read and write. that is why the seriallinecontrol is there.

Also that is why there is variable Byte(string-,data-)Received: BOOL variable so that like in example you can make:

REPEAT     Receive(RXbuffer:=RXbuffer);
     IF Receive.ByteReceived 
     THEN         (* evaluate character*) 
     END_IF 
UNTIL NOT Receive.ByteReceived
END_REPEAT

to read all data that is received between read calls.

 

[PlayerByNature]

When I use the fast Task with 'SerialLineControl' and I want to send 240 bytes then sometimes it send 2 times the same package? And i get unpredictable bytes to be send.

That repeat block is nice. But what happen when it take 300ms to receive a byte? System crash?

 

[JesperMP]

I dont believe you have to scan Receive.ByteReceived continously.

Disclaimer: I have zero experience with Beckhoff or Twincat, but what you are are attempting is similar to other types of asyncronous data transmission I have seen.

I am guessing this:
The function call Receive(RXbuffer:=RXbuffer) does all the work. You dont have to and should not run a continous loop to scan for Receive.ByteReceived.
In stead you should call the Receive(RXbuffer:=RXbuffer), and check the Receive.ByteReceived as part of a regular cyclic task.
If you get the Receive.ByteReceived, then you evaluate the byte (or bytes, see below), and probably have to clear the buffer.

Your only worry is that the cyclic task must be fast enough to avoid the buffer being overflooded with data.

I guess that the receive buffer will contain many bytes, not just one byte. That will make the requirement for a cyclic scan far more relaxed.

 

[PlayerByNature]

The receive block is not a problem. But the send block act strange with a fast task.

 

[kamenges]

I would look carefully at your send trigger logic. Depending on how you wrote it you may not have received a send acknowledge before the task executes a second time. This MAY result in a double send.

Keith

 

[PlayerByNature]

Send Acknowledge none exist. Only bussy Flag.

 

[TurpoUrpo]

Post the code you are using to invoke send.

 

[PlayerByNature]

(*Fill the first 5 bytes of the Frame with Header/CMD/Address/Length Data*)
Frame_tx[0]:= 16#80 OR Seq_nr ;
Frame_tx[1]:= CMD;
Frame_tx[2]:= INT_TO_BYTE(Frame_Length) + 4;
Frame_tx[3]:= INT_TO_BYTE(Frame_Length) + 4;
Req_nr:=    (Seq_nr + 1) MOD Max_Frame_Count;
Frame_tx[4]:= addr_Low;
Frame_tx[5]:= addr_High;
Frame_tx[6]:= length_Low;
Frame_tx[7]:= length_High;

(*Fill the rest of the Frame with Data*)
FOR byte_counter1:= 0 TO Frame_Length + 1 BY 1 DO
    Frame_tx[byte_counter1 + 8]:= blkout[byte_counter1];
END_FOR

fb_Checksum(    Data:=    Frame_tx,
                Length:=    Frame_Length + 8);
Frame_tx[Frame_Length + 8]:= WORD_TO_BYTE(Checksum);        (*16 bit CRC*)
Frame_tx[Frame_Length + 9]:= WORD_TO_BYTE(SHR(Checksum,8));

(*Clear the TX-buffer*)
ClearComs(    Buffer:= TxBuffer1);
(*ClearComs(    Buffer:= RxBuffer1);*)

IF NOT Received_False THEN
    (*Send the complete Frame to the BoatLoader*)
    FOR byte_counter2:= 0 TO Frame_Length + 9 BY 1 DO
        Send_Byte(    SendByte:= Frame_tx[byte_counter2],
                      TXbuffer:= TxBuffer1,    (* see global variables *)
                      Busy=> SendBusy,
                      Error=> SendErrorID);
    END_FOR
END_IF

SERIAL_Coms();

SERIAL_Coms is not a Fast Task. Just a PRG in the main task.

Here im sure when the buffer is filled -> the data goes to the hardware.

I clear the TXbuffer manually, cause beckhoff states they only clear automatic when the buffer get overflow.

Received_False variable I want to use as the TimeOut/Receive Flag. The one thing i dislike bout Flags, is that u need to clear them again somewhere.

 

[Peter Nachtwey]

Am I wasting my time here?

Stop. This is a PLC. Yield makes no sense.

WHAT!!!!!???? It sure does if it makes the job easy!!!
What good are standards that don't make your life easy? A jab at the IEC spec.

There is no YIELD function supported for their OS.

So this is not a cooperative multi tasking system, OK and how crude.

Then this is where you use the state machine approach using the CASE OF statements that I wrote about a few days ago in the state machine thread.
IS ALL INFORMATION LOST AND FORGOTTEN WHEN IT SCROLLS OFF THE FRONT PAGE OF THIS FORUM? DID ANYONE UNDERSTAND WHAT I WAS TRYING TO SHOW IN THE STATE MACHINE THREAD?
If SFC is available then that will work too and may be better or clearer.
With that hint lets see if someone can figure it out now.

 

[TurpoUrpo]

There is more than one byte, you should use send data fb. Use right tool.

SendDataVAR_INPUT
pSendData : POINTER TO BYTE;
Length : UDINT; END_VAR VAR_OUTPUT
Busy : BOOL;
Error: [URL="http://www.plctalk.net/qanda/TcPlcLibSerCom_Appendix_Errorcodes.htm"]ComError_t[/URL];
END_VAR
VAR_IN_OUT
TXbuffer: [URL="http://www.plctalk.net/qanda/TcPlcLibSerCom_Struct_ComBuffer.htm"]ComBuffer[/URL];
END_VAR

SendDataDescription

SendData sends the contents of a variable of any type to the interface corresponding to the input variable TxBuffer. For as long as Busy=TRUE, the transmission is not completed. The data has successfully been sent when Busy=FALSE and Error=0.
pSendData

pSendData is the address of the send data, and is determined by means of ADR(send data).
The data must not be changed as long as Busy is TRUE and the transmission is not completed.
Length

Length is the number of data bytes to be sent, and can be smaller than or equal to the size of the data structure being used. If the entire contents of a variable are to be sent, then the length can be determined using SIZEOF(send data).

You have made for loop where you send new data without checking if data have finished sending.

 

[PlayerByNature]

There is more than one byte, you should use send data fb. Use right tool.

You have made for loop where you send new data without checking if data have finished sending.

Thats true. But then again i need a state machine.

I wrote so many state machine code now.

The 'SerialLineControl' in a fast Task of 1ms, will it send data in the Txbuffer even the bussy flag is still True?

 

[PlayerByNature]

The state machine is indeed the solution. I wrote so many state machine code, I wanted to write a block without. But never the less.