Problems with multiple State Transitions

[cmmffhc]

Hi,

i have some problems with state transitions:

an example of my program is:

in-state 1
condition
conf @ 3 > conf @ 3 = OR
causes
then-state 2 to-happen

in-state 1
condition
conf @ 3 < confcount count AND \ confcount is a loopindex
causes
2500 pwma0 pwm-out
then-state 3 to-happen

basically, i want to go to state 2 when conf is 3 or more and do no actions, and i want to go to state 3 when conf is less than 3 AND confcount reaches its terminating number...

the problem i face is that when conf is more than 3, it successfully goes to state 2 BUT yet the causes of "2500 pwma0 pwm-out" is still carried out when the condition was never true!!

why?? can anyone help?

thanx..

[RMDumse]

It took a little bit to see what you were doing, but I think I see it now.

You defined the states with names of numbers, perhaps like this

MACHINE XXXX
ON-MACHINE XXXX
APPEND-STATE 1
APPEND-STATE 2
APPEND-STATE 3

Then later in the program you try to use the number 3 in the program. But when the line is translated, the number 3 is no longer used, because 3 has been redefined to be something else, a state, and not just the numeric value 3. So what is compiled is not what you were expecting.

Perhaps you could rename your states as S1, S2, S3, or other unique name and see if that doesn't help move thing along.

[cmmffhc]

Thanx for the help...i'm sorry but in my actual code i did not use numbers for the states. i used words like cam, initcam, scan1....eg...

i found that the problem seems to lie with the synchronization of some of my machines...

for example...i have a machine that have:

CAUSES
2500 pwma0 pwm-out
CHECKCAM \ check cam is something that should be executed after the
servo motor has moved to the required pwm...

i suspect CHECKCAM was executed before the motor moved...perhaps due to the delay in the motor reacting to the pwm output...do u think that is a possibility? If so is there anything i can do about it?


i also have another problem that is:

in-state XXX
condition .....
causes
CHECKCAM
then-state YYY
to-happen

in-state YYY
condition
( the condition here requires checkcam to be completed first )
causes .....
then-state ... to-happen ...

Here, my problem seems that when my machine transits to YYY, the condition clause is checked before CHECKCAM successfully finish executing... this causes huge problems in my machines...


I hope you can understand what i am trying to say! so sorry if it is difficult to understand!! but i really need some help! thanx!!

[RMDumse]

i suspect CHECKCAM was executed before the motor moved...perhaps due to the delay in the motor reacting to the pwm output...do u think that is a possibility? If so is there anything i can do about it?

Yes, definitely. There will be a delay between assigning a new PWM and the PWM actually coming out. This delay will typically be at least one servo period, or depending how what you're using for a time base, 76Hz to 60Hz. Then there will be another delay, a mechanical one, necessary for the servo to respond to the commanded position and run the motor and gear train before the horn reaches the commanded position.

While you can look into the manual on the PWM registers and find out which bits will tell you when the new pulse is loaded, there's nothing that can be done to know the settling time for the mechanical part of the system.


i also have another problem that is:

in-state XXX
condition .....
causes
CHECKCAM
then-state YYY
to-happen

in-state YYY
condition
( the condition here requires checkcam to be completed first )
causes .....
then-state ... to-happen ...

Here, my problem seems that when my machine transits to YYY, the condition clause is checked before CHECKCAM successfully finish executing... this causes huge problems in my machines...


It seems you are going to have to wait for the servo to respond. Any time you have a wait, you need a state. So it would be best to put another wait inbetween where you command the servo change, and where you do CHECKCAM. This will solve the first problem above. Then after CHECKCAM you will need another wait for CHECKCAM to complete, before continuing on. That will solve the second problem above.

It's just the nature of statemachines, if there's a wait, there's a state. They only work when you have all the waits specified, otherwise the machine moves too quickly, particularly when "slow" mechanical systems are involved.

[cmmffhc]

Thanx a lot! you've been a great help!