IDE 4.3 bug report

[jojege01]

Hello, I am sang joon Lee.

 

I am reporting an IDE bug, maybe a compile-time bug.

 

When calling a P-variable, for instance, p100, and not assigning any value to it

within a motion program, calling the program does not go further down from the variable call.

It stops at p100.

 

The followings are my code.

 

open prog 1

Ldata.motor = 1

p100(here)

motor[1].progjogpos=10000;

Jog =*;

call Timer.msec(100);

while(motor[1].inpos==0 || motor[1].desvelzero==0) {}

m14

close

 

open prog 1001

N14000

dwell(0)

motor[1].JogTa=-5

motor[1].JogTs=-30

motor[1].JogSpeed=60

motor[1].progjogpos=0

Ldata.motor=1

Jog=*;

call Timer.msec(100);

while(Motor[1].desvelzero==0) {}

return

 

Well, the code does not fail at download.

if I put P100=1 instead of P100, the program works.

I guess it halts on runtime error.

However, IDE did not catch when compiling the program.

 

I used CK3M and omron 1S driver.

CK3M firmware : 2.5.2.0

IDE version : 4.3.2.19

 

Thank you.

[Omron Forums Support]

Sang Joon Lee,

 

What are you trying to do with the P100 line? A variable by itself doesn't really mean anything in PMAC script.

[jojege01]

Sang Joon Lee,

 

What are you trying to do with the P100 line? A variable by itself doesn't really mean anything in PMAC script.

 

Hi, history of this is, I visited a user and he has a program that generates PMAC program script, includes G code, from CAD.

One of his scripts includes "P0360" at line number 3 or 4.

 

I told the user not to include a variable call as shown.

And I have tested as follows.

 

open prog 1

p100

abs

close

 

prog 1 is ok

 

open prog 2

q100

p100=62

abs

close

 

prog 2 stops

 

open prog 3

i100

p100=63

abs

close

 

prog 3 is ok

 

#define Slave_1001_R88D_1SN01H_ECT_1001_60B8_0_Touchprobefunction ECAT[0].IO[2].Data

ptr Latch -> ECAT[0].IO[2].Data

open prog 4

Latch

p100=64

abs

close

 

prog 4 assume Latch as a M-code call, Latch=M8192 in my case.

It is ok though.

 

and TurboPmac accepts the following program.

 

OPEN PROG 1 CLEAR

p100

p100

p100

p100

p100

i122=10

m172=5000

X (m172)

I5111=100*8388608/I10

WHILE(I5111>0)

ENDWHILE

while(M133=0 or M140=0)

endwhile

G14

CLOSE

 

calling p100 in script is accepted in TurboPMAC but PowerPMAC does not.

[Alex Anikstein]

Sang Joon,

 

That doesn't really answer the question, though. I understand that the customer's code includes the line "P0360", but why does it include this? Even if this did not cause an error, at best, this line does nothing, and as such, we would recommend your customer remove this line.

 

Querying a variable should not be a valid command for inside of a motion program or PLC--if anything, I would argue that it should not have been accepted in Turbo PMAC, not that it should be allowed in Power PMAC.

[jojege01]

Sang Joon,

 

That doesn't really answer the question, though. I understand that the customer's code includes the line "P0360", but why does it include this? Even if this did not cause an error, at best, this line does nothing, and as such, we would recommend your customer remove this line.

 

Querying a variable should not be a valid command for inside of a motion program or PLC--if anything, I would argue that it should not have been accepted in Turbo PMAC, not that it should be allowed in Power PMAC.

 

Sorry.

 

According to my senior, the G-code generator is built for Turbo PMAC. For a number of Turbo PMAC users, calling M variable in script program clears an application system configuration before starting some operations.

 

But Power PMAC does not accept this way of variable call and I need to instruct users not to use querying variables in script programs.

 

And I am reporting this to know if querying a variable is not to be allowed.

[Alex Anikstein]

Sang Joon,

 

There's two different things at play.

I believe querying a P Variable in Turbo would have resulted in a "no-op" (no operation to perform), and the line would have been skipped.

In Power, it was decided to instead catch "no-op"s and send errors when they are encountered.

As such, querying variables this way is not allowed in Power PMAC.

 

However, you mentioned "calling M variables".

This most likely is not simply reading an M Variable, but rather, executing M Code (from the same family as G Code).

In this case, like the "M14" in your very first example program, you are not querying anything, but rather, issuing a command.

As such, this is not a "no-op".

Power PMAC does accept G, M, T, and D Codes, which will look similar to querying variables, but are handled differently.

 

In Power PMAC, the command "P10" should always cause an error in a motion program. "M10", however, will likely tell PMAC to look for Line 10000 in the specified M-Code library.

[jojege01]

Sang Joon,

 

There's two different things at play.

I believe querying a P Variable in Turbo would have resulted in a "no-op" (no operation to perform), and the line would have been skipped.

In Power, it was decided to instead catch "no-op"s and send errors when they are encountered.

As such, querying variables this way is not allowed in Power PMAC.

 

However, you mentioned "calling M variables".

This most likely is not simply reading an M Variable, but rather, executing M Code (from the same family as G Code).

In this case, like the "M14" in your very first example program, you are not querying anything, but rather, issuing a command.

As such, this is not a "no-op".

Power PMAC does accept G, M, T, and D Codes, which will look similar to querying variables, but are handled differently.

 

In Power PMAC, the command "P10" should always cause an error in a motion program. "M10", however, will likely tell PMAC to look for Line 10000 in the specified M-Code library.

 

Hi Alex,

 

understand. I have told the user not to use a bare variable call.

As I know, the user is more familiar with Turbo PMAC but I have been converting his application to Power PMAC.

 

Thank you for your help Alex, Eric!

[JeffB]

Not sure if it's exactly the same thing but I (inadvertently) had a p variable alone on a line in a motion program. No compiler error but the motion program would exit when it reached this line. Took me awhile to debug. Better if there was a compile error.