TestDO

Robot Controller
1

I want to call a routine if a digital output is low. I know you can use TestDI() to look at the state of a digital input. It would look as follows
IF TestDI(myDI) = FALSE myRoutine1;
This wont work for a digital output. I want to do something like this
IF myDO = 0 myRoutine1;

I am doing this on an IRC5 controller if this helps.

Liam

2

I think this should work:

IF DOutput(myDO)=0 myRoutine1;

Best regards,
blinder

3

And what do you say about my problem:

I have a path for my robot, its divided in 7 segments. Each segment is in a different PROC and when the PROC starts I use different virtual DOs to identify later which PROC was, and of course I reset it in the same PROC.

The main idea is that the robot its moving in auto NON stop, then suddenly stops, and the actual DO signal shows, as a “pointer” where is standing the robot and based on this, moves home automatically.

My code: IF DOutput (T1)=1 then …
elseif DO… then …
…
elseif DOutput(T7)=1 then…
ENDIF
I made a button in Screen maker which calls this “Comparation” PROC, I run it only in manual safe mode.
The problem is: The comparation is OK till the 2nd IF, after that the 4th is running but none of the last ones(3,5,6,7). Why?

I tried to divide all these 7 comparation in 3 main IF … instructions, but not resolved.
I realised, maybe the IF instr. cant handle more then 3 ELSEIF instructions, but No, not this is the problem. I have no idea and the time is passing but I cant move forward.

What do you say colleauges? Can you help me?

4

Hi szily85

Are the signals T1 to T7 set correct before you start the IF part?
Did you set the signals after a Move-instruction with a zone? Then the signals do not match with the segment the robot just moved to.
Do you reset all signals before you start again?

Best regards

Marcel

5

Hello Marcel!

Here is a part of my code:
Module1.mod file is working now with no problem, I changed to a Programmable button on TP, not TouchScreen button as you can see on Module2.mod file

But in case of the Module2.mod file, its not “getting in” the 3,5,6,7 step.

If you have time, please look at it, Id like to know whats wrong, to learn from it BUT, I solved already.

Thanks for this fast reply.

Greatings

webwiz/5071/MainModule2.rar

webwiz/5071/MainModule1.rar

6

Hi Szily85

How did you solve this problem?

What I saw in your code:

…

MoveL Approach, v500, fine, tStudWObj:=Wo_ArmeringsBunt;
Reset T1;
Set T2;
MoveJ Turn2, v1000, z150, tStudWObj:=Wo_ArmeringsBunt;
MoveJ Turn3, v1000, z150, tStudWObj:=Wo_ArmeringsBunt;
MoveJ Turn4, v50, z20, tStudWObj:=Wo_ArmeringsBunt;
MoveJ ApproachLabel, v50, z20, tStud_inWObj:=Wo_ArmeringsBunt;
Reset T2;
…

The positioning processor and the I/O processor are synchronized after the fine zone in Approach. The logical operation: Reset T1; Set T2; will be set correctly. But then the positioning process goes true the next operations very quickly to look at the movements in advanced. So Reset T2; will be done just after Set T2; and the signal is on for a very short time or might even never be on.

Use instead:

MoveJDO ApproachLabel, v50, z20, tStud_inWObj:=Wo_ArmeringsBunt,T2,0;

This allows a reset of the signal closest to the ApproachLabel position, synchronized both processes.

Best regards

Marcel

7

Hello Marcel,

when the robot is moving and suddenly stops at one certain point (and this part of the program will be used in manual, safe mode), anyway one of the signals will be SET. Its quite sure that it will not stop on a RESET or SET point. But I resolved, I had to take out the "TPReadFk" section, because it seemed that to many IF instr. just cant be handeled, but of course I`ll try your suggestion and will see. Thanks for help :wink: anyway.

BR
Szily

8

If you are concerned about too many if statements why not anaylze the signals as GO’s and run a test case?

That would clean up the If statement to a test case at least. With a default action available for catching an invalid condition.