The Industrial Raspberry Pi Forum

Hi
Added Virtual 32 bit extended module in pictory and access from Logi.Cal to Node-red works flawlesssy using node-red-contrib-revpi-nodes/revpi single input and revpi getpin. Desired values to be transferred from logical is written in the output pin section of the virtual module (using global variables).

Trouble starts when I want to transfer values to Logi.cal from Node red. The pins configured as 'input' in pictory cannot be changed in logi.cal (defined as global variables), they appear to be reset when altering them in the debug interface. Input pins cannot be altered in Node red afaik.

How are the virtual input pin expected to function? And how to access this in Node red?

BR, Anders / Biowaste2Gas

Hi again
Testing the virtual input function in piTest using write to the named input pin in the virtual module confirms that the input cannot be read in logicad.

piTest - w UA_SYS_start_I,1

Does not alter the value in logicad, but piTest yields a '1'.

The pins in question from the export from Pictory:

UA_SYS_start_I AT %IW1.406: WORD := 0; //
UA_SYS_stop_I AT %IW1.408: WORD := 0; //

ST program declaration:

UA_SYS_start_I : WORD;
UA_SYS_start_O : BOOL;
UA_SYS_stop_I : WORD;
UA_SYS_stop_O : BOOL;

By using the debug window in Logicad, I cannot read the value even though it is altered using piTest. Stopping the program and altering the value in Logicad does not reflect on piTest -r UA_SYS_start_I neither

Again, can anyone explain how the input on the virtual module is supposed to work in relation to logicad? I cannot get the expected result.

The output registers are working fine, but these cannot be altered in Rednode afaik.

Anyone with the knowledge on how Pictorys virtual modules are supposed to work in relation to logicad?

BR, Anders

Hi
It starts to get interesting... I have given up on the input pin and focus on the output pin in process variable from PICtory.

The UA_SYS_start_O pin CAN actually be manipulated by Node-red.... Running piTest -r UA_SYS_start_O and setting UA_SYS_start_O high in Node-red yield different results.

There seems to be an inter-process lock in place, the Node-red code can manipulate the output pin as long as the Logical code is not running. And vice-versa, if the Node-red has gained write access, for some reason ST loses also the read access. That puzzles me as the Node-red code has great read access to all the process variables independent of the ST code running or not.

So in fact both sets of code (ST+Node-red) is working just fine, just not concurrently.

It is somewhat over my ambition level to try and solve this interprocess battle of control over the process variable.

So - suggestions for other ways of establishing communication from Node-red to Logical?

BR, Anders

Hello Anders, thank you for your patience. Thank you for your detailled report. For me you did exactly the right thing. You have used a Virtual Module in PiCtory for the data exchange between your applications.
I have requested for help from logi.cad here. I hope that we are able to help you here and to uderstand the root cause of the error.

Hi Dirk
Thanks for reply.
I dug a bit deeper and now the communication is running using a MQTT broker (like your PICtory AFAIK?). The broker is initialized in NodeRed and the LogiCAL MQTT library interface is used for information transfer.
However, the NodeRed publishes a string 'True'/'False' and not a binary value. But that is manageable for now.
Based on experience I think the rootcause is the ClientID used to access the MQTT broker by Pictory/Logical/Nodered, if these are not different, the broker randomly changes client (W/O being expert, only by observation).
BR, Anders

Hi Anders,

thank you for your insights. I have made an issue for your request on our github: https://github.com/erminas/node-red-con ... s/issues/9 so others users with the same problem can follow along.

To answer some of your questions:

>There seems to be an inter-process lock in place, the Node-red code can manipulate the output pin as long as the Logical code is not running.

You are correct, you can read a bit about this from our (RevPi Node) perspective here: https://github.com/erminas/noderedrevpi ... er#remarks and here https://revpimodio.org/en/doc2/

shared_procimg
= Write outputs without buffer to process image (WARNING) Only activate this option in exceptional cases with True!
RevPiModIO uses an internal buffer for IOs, which significantly increases the speed and ensures that the values from the Python program are guaranteed to be in the process image as well.
If multiple instances or programs are using the process image, each instance would constantly set its outputs and create a messy state (flickering outputs / false input values).
If this option is activated, the outputs are written directly to the process image when a new value is assigned. If many outputs are changed per cycle, this could affect performance.
Note: It must be expected that an output that the Python program sets to True
can already be False
in the next cycle if it has been changed by another program in the process image.

I can't talk for Logi.Cals, but it seems it uses a tight coupling with an internal buffer to the proccess image. As described in our readme, we don't use an internal buffer so other programs can still overwrite the outputs in pictory. This comes with its own problems.

> However, the NodeRed publishes a string 'True'/'False' and not a binary value. But that is manageable for now.

If you add some further detail which nodes for you are using we can discuss some possible changes to the RevPi Nodes in that regard.

There is a similar thread here with suggestions including using mqtt from logi.cals: viewtopic.php?t=1906#p7248. Its in german, but maybe you read it with a translator.

Greetings,
Jonas

Hi Jonas
Thanks for the details! I have everything up and running using the MQTT-broker. I use simple encoding and a integer to reflect the status on the UI.
BR, Anders