Some things i cannot figure out with sysmac

[SKA AB 7]

Hi.

I have currently a project to convert a bunch of PLC's from ST to Ladder, and have struck up on some wierdness.
When i create a new Ladder block, i copy all internal and In/Out variables to the new block.
But when i start to copy variable names into the ladder logic, some variables does not exist anywhere in the project, at all.
In ST it compiles without any error nor warnings. But in ladder it turns up as as error.

Quote

Error    2545    Specify the enumerated data type name.    FB_SM_Handler_New    Row 45

Also, i have variables (or perhaps structs?) that is called like MOTOR_Handler_Z, (or _X or _Y). I cannot find theese either, but these compile just fine, is this some CPU variables that "just exists" like P_On and P_Off?

 

I have 2 screens and use MS PowerToys to get "FancyZones", specially on the second screen, yesterday i tried to detach one of the blocks from sysmac and put it in the 2nd screen, this does not seem to work as expected. Either the window ends up half way off the second screen, or it just vanishes off screen and cannot be found anymore. In Powetoys i hold Shift and drag the window to the zone area trying to make it take up the defined space. Dont know if it matters if the 2nd screen is in potrait mode.

[BE 11]

When you say "copy variable names into the ladder logic", are you referring to the variable names that you previously copied and pasted (in/out and internal)?

In your variable table in the function block, are their any variables that don't have a datatype?

[SKA AB 7]

10 hours ago, BE said:

When you say "copy variable names into the ladder logic", are you referring to the variable names that you previously copied and pasted (in/out and internal)?

In your variable table in the function block, are their any variables that don't have a datatype?

Yes on the first one, and no on the second one.

The variables is just a straight copy from the ST code, but does not exist anywhere

[BE 11]

The variables you are copying, are they variables inside the actual function block or are they the variables that you are assigning to the inputs/outputs of an instance of the function block in the PLC code?

I can't say I have experienced what you are seeing. The only time I had similar problems is when I have:

Copied global variables into a program, without them being registered

Changed from ST to ladder logic, but haven't used the right function for a given datatype (typically datatype mismatch when comparing variables or similar)

When a variable has been registered automatically, but Sysmac Studio can't work out what type it is

 

If it's none of those, then I really don't know. 

[SKA AB 7]

7 hours ago, BE said:

The variables you are copying, are they variables inside the actual function block or are they the variables that you are assigning to the inputs/outputs of an instance of the function block in the PLC code?

I can't say I have experienced what you are seeing. The only time I had similar problems is when I have:

Copied global variables into a program, without them being registered

Changed from ST to ladder logic, but haven't used the right function for a given datatype (typically datatype mismatch when comparing variables or similar)

When a variable has been registered automatically, but Sysmac Studio can't work out what type it is

 

If it's none of those, then I really don't know. 

 

Inside both FB.

Local to local, IO to IO parts copied and pasted.

 

Here is one example in an image.The lower ST part, compiles without problems.

Same code, in the same project under the same "folder"/structure thrown an error.

 

 

So this amazes me that the PLC actually work, unless ST is like javascript and auto declare stuff, which seems not so good in my book.

When i search for one of the variables, sure i can find it in a enumerate, but i would assume i would need to declare a variable as a AOI_In_State type or something similar.

[BE 11]

I haven't used Enumerators before, but a quick google (youtube is great), and a quick test in my dummy program indicated that when referencing the Enumerator, you need to type EnumeratorName#MemberName

So in your case, it would be AOI_In_State#AOIIN_ReadyForTest instead of just AOIIN_ReadyForTest

Can't be 100% sure as I have never used them before in one of my programs, but maybe try that and see what happens

[SKA AB 7]

8 hours ago, BE said:

I haven't used Enumerators before, but a quick google (youtube is great), and a quick test in my dummy program indicated that when referencing the Enumerator, you need to type EnumeratorName#MemberName

So in your case, it would be AOI_In_State#AOIIN_ReadyForTest instead of just AOIIN_ReadyForTest

Can't be 100% sure as I have never used them before in one of my programs, but maybe try that and see what happens

I have never used it my self, but looking in the ST code, i cannot be 100% sure its actually the enum its points at, unless the ST-Code auto-points it it self, nor have i've seen a similar do "USE" or "IMPORT" reference (if that works in ST) to import other namespaces so you dont need to reference the full/complete path to something.

 

[BE 11]

Just checked in in Sysmac Studio, Enumerator members can't have the same name as any other enumeration datatype members, including different enumeration datatypes. So if I have 2 enumerators, called Enum1 & Enum2, none of the member names of Enum2 can be the same as the member names of Enum1 and vice versa. 

So I would go out on a limb and suggest that ST automatically finds the right datatype name, because member names have to be unique. Does make me wonder why ladder logic doesn't do the same thing, maybe someone else has some insight on that.

Edited 2 Nov 2022 by BE

[SKA AB 7]

On 11/1/2022 at 11:16 PM, BE said:

So in your case, it would be AOI_In_State#AOIIN_ReadyForTest instead of just AOIIN_ReadyForTest

I just got around to test this, this works and removes errors/warnings about this..

 

Still unsure why it works in ST code without AOI_In_State# and must be declared in Ladder.

[EdAll 0]

The DataType# is required more often in Ladder. Especially when the Fun/FB input has no datatype defined. (Says Any) It has something to do with the compiler checks for Ladder.