Activity for aliazzz

  • aliazzz aliazzz modified a comment on discussion Runtime πŸ‡¬πŸ‡§

    Just to chime in my two cents. I have had my fair share of issue's with soft containers, migration, SD Cards dying etc etc. This caused me to lose my softcontainer license more then once. After many struggles I decided to stop stressing and losing time on such things and I bought a hardware dongle and since then I never had such issues again. Just plug and play! Plus the license is dongle locked and not device locked in contrary with softcontainer based ones. So when you upgrade your hardware, you...

  • aliazzz aliazzz modified a comment on discussion Runtime πŸ‡¬πŸ‡§

    Just to chime in my two cents. I have had my fair share of issue's with soft containers, migration, SD Cards dying etc etc. This caused me to lose my softcontainer license more then once. After many struggles I decided to stop stressing and losing time on such things and I bought a hardware dongle and since then I never had such issues again. Just plug and play! Plus the license is dongle locked and not device locked in contrary with softcontainer based ones. So when you upgrade your hardware, you...

  • aliazzz aliazzz modified a comment on discussion Runtime πŸ‡¬πŸ‡§

    Just to chime in my two cents. I have had my fair share of issue's with soft containers, migration, SD Cards dying etc etc. This caused me to lose my softcontainer license more then once. After many struggles I decided to stop stressing and losing time on such things and I bought a hardware dongle and since then I never had such issues again. Just plug and play! Plus the license is dongle locked and not device locked in contrary with softcontainer based ones. So when you upgrade your hardware, you...

  • aliazzz aliazzz posted a comment on discussion Runtime πŸ‡¬πŸ‡§

    Just to chime in my two cents. I have had my fair share of issue's with soft containers, migration, SD Cards dying etc etc. This caused me to lose my softcontainer license more then once. After many struggles I decided to stop stressing and losing time on such things and I bought a hardware dongle and since then I never had such issues again. Just plug and play! Plus the license is dongle locked and not device locked in contrary with softcontainer based ones. So when you upgrade your hardware, you...

  • aliazzz aliazzz posted a comment on discussion Forge πŸ‡¬πŸ‡§

    Hi Breta, Sorry to react a bit late. The Monarco driver you are using will not be developed further. If you wish to use the HAT with CODESYS, I suggest you use driver v1.0.0.0 as it is more complete. Also all the drivers are open source so you are permitted to do anything you like and write extra functionality into them. With kind regards Aliazzz Talk Topic about project #breta111

  • aliazzz aliazzz modified a comment on discussion Engineering πŸ‡¬πŸ‡§

    No, an IO point can only be connected to a single variable. However, you can read from this single variable from several parts in the application. Plus there are other workarounds thinkable to overcome this. Just some mock code (example) not to be taken too litteral HW_IO.CH1 => Ch1Var // DI Ch1 FB_X.In1 := Ch1Var; // assign to X.1 FB_Y.In1 := Ch1Var; // assign to Y.1 FB_Z.In1 := Ch1Var; // assign to Z.1

  • aliazzz aliazzz modified a comment on discussion Engineering πŸ‡¬πŸ‡§

    No, an IO point can only be connected to a single variable. However, you can read from this single variable from several parts in the application. Plus there are other workarounds thinkable to overcome this. Just some mock code (example) not to be taken too litteral HW_IO.CH1 => Ch1Var // DI Ch1 FB_X.In1 := Ch1Var; // assign to X.1 FB_Y.In1 := Ch1Var; // assign to Y.1 FB_Z.In1 := Ch1Var; // assign to Z.3

  • aliazzz aliazzz posted a comment on discussion Engineering πŸ‡¬πŸ‡§

    No, an IO point can only be connected to a single variable. However, you can read from this single variable from several parts in the application. Plus there are other workarounds thinkable to overcome this. HW_IO.CH1 => Ch1Var // DI Ch1 FB_X.In1 := Ch1Var; // assign to X.1 FB_Y.In1 := Ch1Var; // assign to Y.1 FB_Z.In1 := Ch1Var; // assign to Z.3

  • aliazzz aliazzz posted a comment on discussion Engineering πŸ‡¬πŸ‡§

    Correct, now you can instanciate multiple FB with the same repeatable code and still connect them to different IO.

  • aliazzz aliazzz posted a comment on discussion Engineering πŸ‡¬πŸ‡§

    Hi, As far as IO mapping goes, I'd steer personally steer clear away from connecting Globals to IO if possible (i.e. when not necessary). Your IO seems to be a part of a (repeatable?) machine. If it is a repeatable machine part, then makes sense to declare an FB (which the contains the repeatable machine code) and instance it and then hook that directly to the IO. Good luck

  • aliazzz aliazzz modified a wiki page

    Home

  • aliazzz aliazzz posted a comment on discussion Engineering πŸ‡¬πŸ‡§

    I suggest a simple approach ;-) Divide all jobs in a separate task: 1) A serial task with a Serial Program. 2) A TCP/IP communication task with a tcp program. 3) A Mqtt to forward signals to MQTT broker. Individual issues can solved in task 1, 2 and 3 appropriatly. Declare a central datastructure in a GVL and write to it from task 1 and 2. Then consume (read) from the GVL datastructure in task 3, which should suffice.

  • aliazzz aliazzz modified a comment on discussion Engineering πŸ‡¬πŸ‡§

    It all depends whether you need a (unique) hash in your solution? If you don't need hash codes in your collection elements, my suggestion would be to remove it. PS instead of searching examples in the store, try searching your examples here. It is a new feature and more convenient IMHO: https://forge.codesys.com/prj/codesys-example/

  • aliazzz aliazzz modified a comment on discussion Engineering πŸ‡¬πŸ‡§

    It all depends whether you need a (unique) hash in your solution? If you don't need hash codes in your collection elements, my suggestion would be to remove it. PS instead of searching examples in the store, try searching your examples here. It is a new feature and more convenient IMHO: https://forge.codesys.com/prj/codesys-example/

  • aliazzz aliazzz modified a comment on discussion Engineering πŸ‡¬πŸ‡§

    It all depends whether you need a (unique) hash in your solution? If you don't need hash codes in your collection elements, my suggestion would be to remove it. PS instead of searching examples in the store, try searching your examples here. It is a new feature and more convenient IMHO: https://forge.codesys.com/prj/codesys-example/

  • aliazzz aliazzz posted a comment on discussion Engineering πŸ‡¬πŸ‡§

    It all depends whether you need a (unique) hash in your solution? If you don't need hash codes in your collection elements, my suggestion would be to remove it.

  • aliazzz aliazzz posted a comment on discussion Engineering πŸ‡¬πŸ‡§

    If you look at this part of the example, you can build it yourself.

  • aliazzz aliazzz posted a comment on discussion Engineering πŸ‡¬πŸ‡§

    Hello, Since the Collection Elements are FB types you can program whatever you wish. So implementing a REAL or LREAL will not be an issue. Either you implement the Collection Interface or you extend collection FB type (read the extensive help on it). If you do this you can design your own Element FB types. This choice is up to you. On "dynamic" collections: In theory there is no limit to maximum size of the collection, but please read the following article very very carefully. https://help.codes...

  • aliazzz aliazzz modified a comment on discussion Engineering πŸ‡¬πŸ‡§

    Naming conventions are always a topic for hot debate, so I won't touch it. However, what is very interesting in the Shadowing convention, I think, is this: Qualified access can also always be used to avoid shadowing rules. The name of the global variable list can be used to uniquely access a variable in the list. The name of a library can be used to uniquely access elements in the library. The THIS pointer be used to uniquely access variables in a function block, even if a local variable with the...

  • aliazzz aliazzz posted a comment on discussion Engineering πŸ‡¬πŸ‡§

    Naming conventions are always a topic for hot debate, so I won't touch it. However, what is very interesting in the Shadowing convention, I think, is this: Qualified access can also always be used to avoid shadowing rules. The name of the global variable list can be used to uniquely access a variable in the list. The name of a library can be used to uniquely access elements in the library. The THIS pointer be used to uniquely access variables in a function block, even if a local variable with the...

  • aliazzz aliazzz modified a comment on discussion Engineering πŸ‡¬πŸ‡§

    Just an addition on your excellent remark, search for shadowing rules, as this is what you ment I think. This might be usefull when you have several GVLs. When you have several GVLs and the variables also have > the same name. The compiler doesn't know which GVL to use and will throw an error. https://help.codesys.com/webapp/_cds_shadowing_rules;product=codesys;version=3.5.16.0

  • aliazzz aliazzz modified a comment on discussion Engineering πŸ‡¬πŸ‡§

    Just an addition on your excellent remark, search for shadowing rules, as this is what you ment I think. https://help.codesys.com/webapp/_cds_shadowing_rules;product=codesys;version=3.5.16.0

  • aliazzz aliazzz posted a comment on discussion Engineering πŸ‡¬πŸ‡§

    Just an addition on your excellent remark, search for shadowing as this is what you ment I think. https://help.codesys.com/webapp/_cds_shadowing_rules;product=codesys;version=3.5.16.0

  • aliazzz aliazzz modified a comment on discussion Engineering πŸ‡¬πŸ‡§

    Removing the {attribute 'qualified_only'} pragma will not affect the code itself but how the compiler should deal with it. Pragma's are IDE or Compiler directives which tell the compiler/IDE how to deal with the code with which the pragma is decorated. Basicly this pragma tells you you can only access a variable with a namespace or (fully qualified) or not. So {attribute 'qualified_only'} Gvl.MyGlobal or when {attribute 'qualified_only'} is removed MyGlobal // is valid Gvl.MyGlobal // is also valid...

  • aliazzz aliazzz modified a comment on discussion Engineering πŸ‡¬πŸ‡§

    Removing the {attribute 'qualified_only'} pragma will not affect the code itself but how the compiler should deal with it. Pragma's are IDE or Compiler directives which tell the compiler/IDE how to deal with the code with which the pragma is decorated. Basicly this pragma tells you you can only access a variable with a namespace or (fully qualified) or not. So {attribute 'qualified_only'} Gvl.MyGlobal or when {attribute 'qualified_only'} is removed MyGlobal // is valid Gvl.MyGlobal // is also valid...

  • aliazzz aliazzz modified a comment on discussion Engineering πŸ‡¬πŸ‡§

    Removing the {attribute 'qualified_only'} pragma will not affect the code itself but how the compiler should deal with it. Pragma's are IDE or Compiler directives which tell the compiler/IDE how to deal with the code with which the pragma is decorated. Basicly this pragma tells you you can only access a variable with a namespace or (fully qualified) or not. So {attribute 'qualified_only'} Gvl.MyGlobal or when {attribute 'qualified_only'} is removed MyGlobal // is valid Gvl.MyGlobal // is also valid...

  • aliazzz aliazzz modified a comment on discussion Engineering πŸ‡¬πŸ‡§

    Removing the {attribute 'qualified_only'} pragma will not affect the code itself but how the compiler should deal with it. Pragma's are IDE or Compiler directives which tell the compiler how to deal with the code with which the pragma is decorated. Basicly this pragma tells you you can only access a variable with a namespace or (fully qualified) or not. So {attribute 'qualified_only'} Gvl.MyGlobal or when {attribute 'qualified_only'} is removed MyGlobal // is valid Gvl.MyGlobal // is also valid As...

  • aliazzz aliazzz modified a comment on discussion Engineering πŸ‡¬πŸ‡§

    Removing the {attribute 'qualified_only'} pragma will not affect the code itself but how the compiler should deal with it. Pragma's are IDE or Compiler directives which tell the compiler how to deal with the code with which the pragma is decorated. For all info on using Pragma's see: https://help.codesys.com/api-content/2/codesys/3.5.13.0/en/_cds_using_pragmas/#id3

  • aliazzz aliazzz posted a comment on discussion Engineering πŸ‡¬πŸ‡§

    Removing the ~~~qualified_only~~~ pragma will not affect the code itself but how the compiler should deal with it. Pragma's are IDE or Compiler directives which tell the compiler how to deal with the code with which the pragma is decorated. For all info on using Pragma's see: https://help.codesys.com/api-content/2/codesys/3.5.13.0/en/_cds_using_pragmas/#id3

  • aliazzz aliazzz modified a comment on discussion Engineering πŸ‡¬πŸ‡§

    Yup, afaik actually he's using V3.. So instead of using pointers, use references as they are compiler safe, while pointers are not. In usage it does not quite differ in idea apart from some minor syntax differences. https://help.codesys.com/webapp/_cds_datatype_reference;product=codesys;version=3.5.16.0 According to the documentation a reference has the following advantages over a pointer: Easier to use: A reference can access the contents of the referenced object directly and without dereferencing....

  • aliazzz aliazzz posted a comment on discussion Engineering πŸ‡¬πŸ‡§

    Yup, afaik actually he's using V3.. So instead of using pointers, use references as they are compiler safe, while pointers are not. In usage it does not quite differ in idea apart from some minor syntax differences. https://help.codesys.com/webapp/_cds_datatype_reference;product=codesys;version=3.5.16.0 Also consider using structures instead of Byte/Word blobs... https://help.codesys.com/api-content/2/codesys/3.5.13.0/en/_cds_datatype_structure/#b2e3e6da93f532b0c0a8640e011c7a1d-3s-structures

  • aliazzz aliazzz posted a comment on discussion Engineering πŸ‡¬πŸ‡§

    Hi, I'd like to give you the advice to avoid using direct adressing(!) In CODESYS it is not neccesary to use it allthough it is permitted. On the other hand, just because it is permitted, doesn't mean that is a good way to do things. Example: On an Digital In IO card Channel 1 you simply declare eg: Pump1_Feedback. While in fact the actual addres for this IO var is %IB0.0 just use the named variable Pump1_Feedback in your code, at least it says what the IO means so the maintenace man can understand...

  • aliazzz aliazzz committed [r413]

  • aliazzz aliazzz modified a wiki page

    Home

<< < 1 .. 4 5 6 >