Serial communications

[BC SYSTEMS]

Hi,

I'm using the following print command to send a string out or comm port 1.

PRINT #1 "50002404000E00403A" + chr$(13)    

A$ = INPUT$(1)

The data from the device is received at A$ no problem in the following format:

506125050E00400BB913

I'm only intrested in the last four bytes of data before the CS i.e 0BB9 when this is converted from hex to dec I get 3001.

I then want to put this value into a DM so my HMI can access the variable.

Not even sure where to start with this so any help appreciated.

Cheers

[support]

You can get the last four bytes of any string in A$ using the following:

IF LEN(A$) >= 4
  B$ = MID$(A$, LEN(A$)-3, 4)
ENDIF

Since B$ is Hex data you convert into a number using the HEXVAL function:

DM[1] = HEXVAL(B$)

[BC SYSTEMS]

Thanks, I would have been ages on that!

I had to change it slightly as the above included the checksum to:

IF LEN(A$) >= 4
  B$ = MID$(A$, LEN(A$)-5, 4)  // -5
ENDIF

Since B$ is Hex data you convert into a number using the HEXVAL function:

DM[1] = HEXVAL(B$)

Many thanks

[BC SYSTEMS]

Hi Guys,

I'm seeing differnt results using the simulator and actual program in the PLC.

In SIM mode.

I'm using the following command:

PRINT #1 "50002404000E00027A"

I send back via the popup screen.

506125050E00400BB913

I then use the following to get the data I want

IF LEN(A$) >= 4???' LOOK TO SEE IF RETURN STRING IS > 4
SETIO RX_LED???' SET RX LED
B$ = MID$(A$, LEN(A$)-5, 4)' COPY LAST FOR BYTES (-5) AND NUMBER OF BYTES LONG
A = A + 1???' COUNTS DATA RECEIVED
CLRIO RX_LED ' CLR TX LED
ENDIF

DM[1] = HEXVAL(B$) 'CONVERT RECEIVED DATA FROM HEX TO DEC

The last four bytes are 0BB9, when converted and stored into DM[1] I Get 3001 - this works perfectly.

PLC Mode

When I monitor the PLC program with a serial program called Listern32, the string the plc sends out is

11:59:39:469  04-Apr-2011 Port  9 - 50002404000E00027A[CR]
50002[SP]A"[STX][STX][STX]*[ENQ][DC3]&[CAN]27A[CR]
50002404000E00027A[CR]
50002404[SP]A[STX]*[ENQ][DC3]&[CAN]27A[CR]
50002404000E00027A[CR]
50002404000[NUL]A[STX][STX][DC2]:[NL]Ux50002404000E00027A[CR]
0002404000E00027A[CR]
50002404000E00027A[CR]
50002404000E00027A[CR]
50002404000E00027A[CR]
50002404000E00027A[CR]
50002404000E00027A[CR]
5000240[SP]A[STX][STX]*[ENQ][DC3]&[CAN]27A[CR]
50002404000E00027A[CR]


as you can see the communication is garbled every now and then with some [STX][STX]*[ENQ][DC3]& characters??

when I send back

506125050E00400BB913[CR]

The PLC reads the data  from A$, in B$ I read 1CL4 and the DM has 7508 insted of 3001

Any Ideas??

Cheers

[support]

Those non printable characters did not come from the PLC using PRINT #. So they must have come from your 3rd party device. Is this an RS485 port that you are monitoring the exchange between the PLC and the device using the U-485 adapter?

[BC SYSTEMS]

Hi,

I run the program in the PLC (TMD2424) and capture the data from the RS232 port using the Listen32 program.  after a few strings I pause the PLC, stop the Listen program and go online with the PLC using the same port.  No other hardware is present??

I tried watching with my U485 but i cannot get it to connect to the PLC?? (seperate issue!!)

Works a treat in simulation but not in real life??

Cheers

[support]

Your "real life" wasn't quite real-life after all as you are involving the PLC going online monitoring via the same COM port.

We would suggest you monitor the PLC via the RS485 port and you can use a HyperTerminal to send test strings to the PLC via the RS232 port.

[BC SYSTEMS]

Guy's

To clarify.

I'm not trying to capture the strings and monitor online via the same comm port.  As below I send some strings from the PLC via a 1 sec pulse, I use the serial tool to capture the data and send some strings back.

I use the same tool onsite where the device is located without any additional characters appearing in the strings. See attached.

I will try to monitor online via the RS485 if i get the U485 working.....

Cheers

[support]

In your screen capture there isn't STX][STX][STX]*[ENQ] type of non-printable ASCII characters mentioned in your email.

[BC SYSTEMS]

Correct, this is captured from the serial tool connected to the actual device.

I dont get these additional characters which is why i thought maybe the PLC was generating them??

Will update when I get new data.

[support]

If executed correctly the PLC would not send out those non-printable characters. You should ensure that you only have function that execute PRINT # statement and not intermixed with other custom functions that could be sending binary characters using OUTCOMM.

[BC SYSTEMS]

Hi Guys,

It looks like my generic USB serial port was causing the errors??  I don't know whay as I cannot  re-produce the errors but as a precaution have placed it in my box of bits for worring about later!

I have now got my U485 up and running and all looks great.

Thaks for the help.

Cheers

[BC SYSTEMS]

Hi guys,

Can you help as I'm pulling my hair out on this one.

I'm using a sequencer to step through my program, each step sends out a different string.  the sequencer is advanced via relay NEXT_CALL.  this sequencer just goes round in circles as long as the data is coming in.  Each step has a fixed 1 second timer contact in series with the sequence step to re-call the custfn

Each call sends a string out of comm 1.  If no data is received I increment B and return to the caller forever..... B counts the transmit attempts

If data is received, I convert the data from hex to dec and store in DM

• and increment A.

when A >0 i want to move on to the next custfn for the next string etc.

This all works fine except after data has been received I want to move on and not re send the same string.

If you look at the attachement you will see I send the data out to my serial listerning tool a couple of times then I force a reply (highlighted in blue)  at this point I want to move  to the next custfn but I always send the original string before moving on to the next string and I cannot get rid of it!

I have tried only sending the string out of comm 1 if A = 0 but this doesnt stop this happening either.....  i.e

IF
A = 0
PRINT #1 "50002402000E00027A"
ENDIF

***********ACTUAL CODE****************

CLRIO NEXT_CALL



SETIO TX_LED_RELAY                     ' SET TX LED
PRINT #1 "50002402000E00027A"              ' ASK CCM FOR SPEED TIMING MAP 0 -255



A$ = INPUT$(1)                        ' CHECK FOR DATA ON COMM PORT 1

IF LEN(A$)= 0
SETLCD 0,0,chr$(1)                     ' 1 SENT TO LCD WILL CLEAR SCREEN
SETLCD 0,1,CHR$(12)                   ' NO CURSOR
SETLCD 1,1, "NO TIMING MAP DATA"    
B = B + 1                           ' COUNTS NO DATA RECEIVED
RETURN                             ' NO DATA HAS BEEN RECEIVED
ENDIF


IF LEN(A$) > 0                        ' LOOK TO SEE IF RETURN STRING IS > 0
A = A + 1                           ' COUNTS DATA RECEIVED
SETIO RX_LED_RELAY                     ' SET RX LED
B$ = MID$(A$, LEN(A$)-5, 4)               ' COPY LAST FOUR BYTES (-5) AND NUMBER OF BYTES LONG
ENDIF

DM[1] = HEXVAL(B$)                      'CONVERT RECEIVED DATA FROM HEX TO DEC

SETLCD 0,0,CHR$(1)                     ' 1 SENT TO LCD WILL CLEAR SCREEN        
SETLCD 0,1,CHR$(12)                   ' NO CURSOR
SETLCD 1,1, "TIMING MAP = " +STR$(DM[1],2)

IF
A > 0                              ' WHEN NUMBER OF REPLIES = 1 MOVE ON TO NEXT CALL
SETIO NEXT_CALL
B = 0
A = 0
ENDIF

[garysdickinson]

I notice that you are using:

CLRIO NEXT_CALL  <-- first line of custom function
SETIO NEXT_CALL  <-- almost last line of custom function

Are you expecting that the RELAY NEXT_CALL will generate a pulse that will advance a COUNTER?  If yes, then this will not work. The ladder logic is suspended until your custom function completes, so the ladder logic will only "see" the final state of NEXT_CALL

If you are going to advance a sequencer no more often than once per second you could do something like the following.  In your custom function you could do a CLRIO NEXT_CALL to disable the sequencer from advancing.
 

[support]

One thing you should understand about the way the PLC handles outgoing string is that after the PRINT #1, the string is stored into an outgoing buffer and the operating system in the PLC employs a serial output interrupt service routine to send out the characters one-by-one until the last character has been sent and the system automatically disable the serial interrupts.

This means that the program execution does not wait for PRINT #1 to complete before it moves on to execute the next statement. This ensures minimum latency for the program execution but if your program has been resending out the same string if it does not receive a response from the device you connect to, could it be that the sequence of characters that was sent out was a result of a previous PRINT #? Maybe you can think along this line to see if that is the cause of the problem you encountered.