Communication difference between V120 & V350

[olivier]

hi,

i am trying to communicate with a weighing system.

i first made a sample project with a V120 everything was working great. I am now coding this into a V350. I first copy the routine use in the V120 (copy and paste cause convert project didn't work) and the code in the V350 didn't work.

Then i try to add manually each instruction "from scratch" it don't work better.

I can't find where is the problem.

My two com port are working for downloading purpose (visilogic) The only way i am investigate is that i got an error 1 in the MI status of the protocol config.And that only in the V350.

here is the 2 code.

Thanks for any help.

essai com v120 light.vlp

essai com V350.vlp

[Ofir]

Hi Oliver,

Do you receive error 1 after power up?

Try first to initialize the V350 and then check if you still receive the same error.

I downloaded your application to V350 and I did not receive any error - I was able also to send the "S" and "T" commands. (I'm using Terminal application to simulate the other device).

Make sure you are using the latest system files (BinLib, Boot and OS).

[olivier]

Ok i didn't check the new firmware vie help-> check for update.

so i now have the last firmware.

but the result is the same.

I sometimes get 1 in mi status (MI 1000) when i send "S" but not each time.

i get -1 in my index (mi1002)

The T (T for tare ) is working great but it don't need an answer .

[Ofir]

Hi Oliver,

Can you check the received string from the other device?

If you get -1 it means that the string configured in Protocol Scan is different from the one you receive,

You can check in INFO mode --> Serial --> Monitor --> port2 RX window whether the received string is exactly as configured in Protocol Scan. (you can switch to HEX mode to view all special charaters.

[olivier]

i have ever done that. This function is very useful anyway...

it's sure i didn't receive what i expect via the "monitor" it seems i receive 5 byte ( the counter inc of 5 in the monitor) and these byte aren't showed in one time in the monitor. I just see the last byte. ( just a note the ability to get back the "old" data receive would be a great feature for debuging...a kind of buffer we can navigate thru)

The problem is that with the V120 to weighing system send me the good answer to the S command. And that without any reboot of any kind.

i really can't see the problem.

the strange thing is that the weighing sys should send me a frame and i see in the monitor as if there was multiple frame.

Thanks for your help...

[Ofir]

Hi Oliver,

It seems that it is an issue with the delay between characters.

First check is there is a configuration in the other device where you can decrease the delay between characters.

If not then try setting a value in SI100 - Maximum Delay between characters (units of 2.5ms) and check whether it helps.

[olivier]

Changing SI100 didn't improve the result.

I made a test that is quite interesting.

I change my protocol scan and i remove the two ETX byte (0D & 0A) and i set an end of frame with a 40 ms silence.

I didn't get a session complete flag and still get -1 in MI 1002.

But in the info mode i can monitor the frame like i am waiting.

i think it can help. no?

i continue my tests

best regards

Olivier

[olivier]

Ok i made a new test that is working

Now in my protocol scan i put my ETX in the line of the frame structure and put an end of frame with a 40 ms silence.

Like that my protocol scan complete well.

The behaviou is quite strange if think? maybe a kind of bug with the ETX with 0D 0A

Best regards

Olivier

[Ofir]

Hi Oliver,

First of all it is good news that the system is working properly now!

The Silence terminator is minimum time to have between the received strings. For example if you set 40ms that means there must be at least 40ms silence between the received strings.Since probably the time between the characters are less than 40ms the PLC collects all the characters and process it properly.

Also since your received string contains the characters 0D0A you must include them in the message body.