Originally created by: scott_cunningham

At Maximilian_K:

Automation drives have status words for fieldbus control. Bits like: is enabled, is faulted, is running, at position, etc. Most PLC programmers are used to global tags, so in each of their POUs you will find the "cardinal sin" of

IF StatusWord.0 = TRUE THEN
   //drive is faulted
   ...
END_IF

which codes in status word bit coding dependency (which is brand specific, or if you are lucky, a standard specific coding).

I hope to have the time to create the "Baby Steps of OOP". We will see. One thing is for sure, however, everyone has an opinion (and they are louder in OOP) on how things "should be done" - which includes myself...!

Hello all,

I've been trying to read and write to a property from the Visualization without luck.

Reading works perfectly using the FRAME* trick stated before in this thread, but when I try to write into the property it never happens.

Do I have to make something special to get this working? Is it possible to write to a property from Visu?

As always thank you in advance.

• FRAME TRICK:
• Create a frame, configure the reference to the property, use that reference inside the frame.

Joan.

Add the pragma {attribute 'monitoring':='call'} in the declaration of the property.

Dear yannickasselin1, we tried that without luck... who knows it could be a Schneider issue...

Any other idea?

Thank you very much in advance!

Originally created by: scott_cunningham

I think the help file specifically said you cannot call properties from a visu entry

@scott_cunningham

Have not looked into the help file (guilty of that), but reading this post l viewtopic.php?f=11&t=7170&start=15#p15982 l some posts before this one in this same thread seems to say the opposite, moreover I've been able to read the value of a property, but not set it.

Originally created by: scott_cunningham

I believe the attribute 'monitoring':='call' is for debugging. It forces a creation of a temporary variable so you can view the get in the online debug mode. Side effect is a property "get" works....

To those who read my article and downloaded the example project I sincerely apologize for having linked to the wrong file. I have discovered and corrected my error.

The example project is here:
http://mitek-automation.com/download_file/199

The article is here:
http://www.controleng.com/single-articl ... 945fb.html m

Part of this video might be helpful (at time 1:25) ...

https://youtu.be/BYUVrKG22Xg?t=5150

As may parts of this article: https://www.isa.org/intech/20161005/

Gary

Hi,
i know the last post is quite old, but i think my questions fits perfect to this topic and discussion in this thread:

Thanks to your posts and examples I start to build up my programm in CodeSys with OOP.

Update: I figured out, that this is not working. But is it possible to get the help window with the FB_INIT?
Whats the benefit of using the VAR_INPUT of the FB_init method instead of the VAR_INPUT in the FB?
For the scott_cunningham example -> put the in the FB:

FUNCTION_BLOCK ClassOilTemperature
VAR_INPUT
   RefTemp : REFERENCE TO UINT;
END_VAR

And then use the FB_init only for linking:

METHOD FB_init : BOOL
VAR_INPUT
   bInitRetains : BOOL; // if TRUE, the retain variables are initialized (warm start / cold start)
   bInCopyCode : BOOL;  // if TRUE, the instance afterwards gets moved into the copy code (online change)
END_VAR
THIS^.RawTemp REF= THIS^.RefTemp;

Because, by using the VAR_INPUT it is possbile to get the help window during object creating:

OilTemp : ClassOilTemperature(

Help Window:

FUNCTION_BLOCK ClassOilTemperature
[b]
VAR_IN[/b]PUT RefTemp REFERENCE TO Uint

Peter

Originally created by: scott_cunningham

VAR_INPUTs in FB_INITs are required during instantiation (so you at least force a reference link at compile). A VAR_INPUT in a FB does not have to be filled (so if the coder does not link, no compile error, but the FB does not work right).

If you insert the instance using the F2 key, then CoDeSys will add the variable to the instance definition.