mondinmr

We need to use two CIFX 50E-DP cards in two Linux PCs running CODESYS for Linux SL (the machines are x86). Has anyone experienced any issues? Do these cards work reliably under Linux?

Double message sorry

I noticed something strange in the trace: one of the variables (specifically parts.servoFeeder.m_pathGen.m_acPos) is showing an absurd or unrealistic value—something around 4E+18. However, when I check the same variable in the watch window, it shows a normal and expected value (around 506). Do you know why there is this discrepancy between the trace and the watch? Could it be a bug in the trace tool? Thanks in advance!

I noticed something strange in the trace: one of the variables (specifically parts.servoFeeder.m_pathGen.m_acPos) is showing an absurd or unrealistic value—something around 4E+18. However, when I check the same variable in the watch window, it shows a normal and expected value (around 506). Do you know why there is this discrepancy between the trace and the watch? Could it be a bug in the trace tool? Thanks in advance!

Hi everyone, I’m investigating a potential issue with a cyclic method we use for reading incremental encoders in our libraries. I’ve come across two implementations that, at first glance, appear to perform the same operation: motionUnit.vlPositionActualValue is UINT due strange encoder type. Version A METHOD PROTECTED cyclicReadField VAR_INST actPosFieldOld: INT; rI: INT; delta: INT; END_VAR rI := TO_INT(motionUnit.vlPositionActualValue); delta := rI - actPosFieldOld; m_actPosRaw := m_actPosRaw +...

Hi everyone, I’m investigating a potential issue with a cyclic method we use for reading incremental encoders in our libraries. I’ve come across two implementations that, at first glance, appear to perform the same operation: motionUnit.vlPositionActualValue is UINT due strange encoder type. Version A METHOD PROTECTED cyclicReadField VAR_INST actPosFieldOld: INT; rI: INT; delta: INT; END_VAR rI := TO_INT(motionUnit.vlPositionActualValue); delta := rI - actPosFieldOld; m_actPosRaw := m_actPosRaw +...

In reality, other vendors are already moving towards integration with VS Code. B&R, for example, is likely the only one that could truly challenge Codesys in the market: they’ve overhauled their once-archaic environment (previously lacking ST OOP) and are now catching up significantly with Automation Studio Code, offering modern programming capabilities and native support for tools like Git and GitHub Copilot. The other big names in the market, frankly, are still light years behind. For smaller projects,...

Good day, I’m writing this message out of frustration regarding the current way project files are saved as encrypted XML and single-file format in CODESYS. I find this approach to be quite tedious for several reasons: Limited Access to Structured Text: Not being able to access Structured Text (ST) externally makes it impossible to work with alternative editors like VSCode. Tools like VSCode are incredibly responsive and feature advanced systems such as GitHub Copilot, which would be a real game-changer...