Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
IDE 4.3 bug report
#1
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.
Reply
#2
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.
Reply
#3
(05-26-2020, 10:16 AM)Eric Hotchkiss Wrote: 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.
Reply
#4
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.
Reply
#5
(05-27-2020, 09:51 AM)AAnikstein Wrote: 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.
Reply
#6
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.
Reply
#7
(05-28-2020, 12:14 PM)AAnikstein Wrote: 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!
Reply
#8
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.
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)