TestDO

LiamGwallace

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

blind3rr

I think this should work:

IF DOutput(myDO)=0 myRoutine1;

Best regards,
blinder

szily85

And what do you say about my problem:

I have a path for my robot, it`s divided in 7 segments. Each segment is in a different PROC and when the PROC starts I use different virtual DO`s 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. can`t handle more then 3 ELSEIF instructions, but No, not this is the problem.

I have no idea and the time is passing but I can`t move forward.

What do you say colleauges? Can you help me?

Marcel

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

szily85

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, I`d like to know what`s wrong, to learn from it BUT, I solved already.

Thanks for this fast reply.

Greatings

webwiz/5071/MainModule2.rar

webwiz/5071/MainModule1.rar

Marcel

Hi Szily85 <?: prefix = o ns = "urn:schemas-microsoft-com:office:office" />

 

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

szily85

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. It`s 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 can`t be handeled, but of course I`ll try your suggestion and will see. Thanks for help  anyway.

BR

Szily

Jwisdom

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.