Welcome, Guest
Username Password: Remember me
Messages posted to this category need to be reviewed by the moderator before it gets posted.
  • Page:
  • 1

TOPIC: Simultaneous messages management on RS485

Simultaneous messages management on RS485 2 months, 1 week ago #2285

  • ABauvin
  • OFFLINE
  • Posts: 2
  • Karma: 0
Hi,
I use 5 motors (class 5). First motor is master and asks for movements to other motors (running their own programs).
Each time a slave motor finishes a movement, it changes a variable in the master (ex: Print1(#129,"a=",c,#13))
The problem is I think sometimes several Print1 messages arrive at same time on master motor; causing some print messages to be ignored (is that possible?)

Could you give me a samrt solution? Or fix the code below?

Code sample:
Slave Motors changing variables depending on their adress

SWITCH ADDR
CASE 2
PRINT1(#129,"n=",c,#13) 'fin de cycle
BREAK
CASE 3
PRINT1(#129,"o=",c,#13) 'fin de cycle
BREAK
CASE 4
PRINT1(#129,"p=",c,#13) 'fin de cycle
BREAK
CASE 5
PRINT1(#129,"q=",c,#13) 'fin de cycle
BREAK
ENDS

MASTER MOTOR (sum all variables modified by slaves motors and compare with target value (value depending on number of motors moving together)
WHILE n+o+p+q<c
LOOP
n=0 o=0 p=0 q=0

I noticed the programm is running master WHILE/LOOP forever (n+o+p+q always<c)

Re: Simultaneous messages management on RS485 2 months, 1 week ago #2286

  • csearcy
  • OFFLINE
  • Posts: 480
  • Karma: 23
The problem your seeing with the RS485 is data collision. If two motors send their PRINT1 commands at the same time, the master will not get either response. It will just be seen as corrupted data and will cause the command error bit to be set.

You may be able to decrease the chance of a collision if you let each motor use it's address to add delays.

Example of spacing PRINT1 statements 10msec apart
SWITCH ADDR
CASE 2
WAIT=ADDR*10 PRINT1(#129,"n=",c,#13) 'fin de cycle
BREAK
CASE 3
WAIT=ADDR*10 PRINT1(#129,"o=",c,#13) 'fin de cycle
BREAK
CASE 4
WAIT=ADDR*10 PRINT1(#129,"p=",c,#13) 'fin de cycle
BREAK
CASE 5
WAIT=ADDR*10 PRINT1(#129,"q=",c,#13) 'fin de cycle
BREAK
ENDS

This method may improve the situation, but will still fail if a data collision occurs due to the motors not finishing their move at the exact time.

The only reliable method will be to have the master poll for the data. Something like below...

'Motor1 (aka Master) program code to detect motion complete on all axes.
'This assumes that all motors have been put into motion already

n=99 o=99 p=99 q=99
WHILE n+o+p+q<c

IF n!=1 nn=99 PRINT1(#130,"GOSUB10",#13) ENDIF
WHILE nn==99 LOOP

IF o!=1 oo=99 PRINT1(#131,"GOSUB10",#13) ENDIF
WHILE oo==99 LOOP

IF p!=1 pp=99 PRINT1(#132,"GOSUB10",#13) ENDIF
WHILE pp==99 LOOP

IF q!=1 qq=99 PRINT1(#133,"GOSUB10",#13) ENDIF
WHILE qq==99 LOOP

LOOP
'All motors have completed their move
END

'Subroutine 10 in motor2 program
C10
c=1-Bt PRINT1(#129,"n=",c," nn=0",#13)
RETURN

'Subroutine 10 in motor3 program
C10
c=1-Bt PRINT1(#129,"o=",c," oo=0",#13)
RETURN

'Subroutine 10 in motor4 program
C10
c=1-Bt PRINT1(#129,"p=",c," pp=0",#13)
RETURN

'Subroutine 10 in motor5 program
C10
c=1-Bt PRINT1(#129,"q=",c," qq=0",#13)
RETURN
The following user(s) said Thank You: ABauvin
  • Page:
  • 1
Moderators: hsummer, csearcy
Time to create page: 0.42 seconds