Publishing external/additional Inputs to ObjectModel

chrishamm

@rero In SBC mode, it doesn't really make sense to use global variables to store SBC-specific data in the object model. Instead, consider defining a custom JSON object in the plugin.json manifest of your new plugin and define it using the data property:

{
  ...
  "data": {
    "myVal": 123
  }
}

and update it using the SetPluginData IPC command:

conn/set_plugin_data("myVal", 456, <plugin ID if plugin is not started by DSF>)

Then you can access it using plugins.<plugin ID>.data.myVal in meta G-code expressions.

See also https://github.com/Duet3D/DuetSoftwareFramework/wiki/Third-Party-Plugins

rero

@chrishamm perfect! That was the detail I was searching for

I will prepare a test-setup with an arduino and some buttons/LEDs to see how it works.

Thanks for your quick help @dc42 and @chrishamm!

rero

So with the usual fiddling around I was able to prepare a test-configuration.

Everything works as expected except one thing: updating the plugin-data via "set_plugin_data".

I declared 4 inputs and 4 outputs in the plugins plugin.json description file. After installing the plugin the object-model looks like this:

Once I modified the plugins data for a single input with this code:

if gOutputs[i]:
  plugin_update_connection.set_plugin_data("IOExample", "output{0}".format(i),"1")
else:
  plugin_update_connection.set_plugin_data("IOExample", "output{0}".format(i),"0")

All the data properties/values are lost and only the last one modified remains:

I tried to lock/unlock the object-model and also to update all 4 inputs in a for-loops, didn't work too...

@chrishamm any idea what is causing this?

chrishamm

@rero Are you using software version 3.5 or 3.6-beta?

rero

@chrishamm I was using stable 3.5.4

Tried unstable 3.6.0-beta2 tonite and got a different behaviour, the connection was closed by the server with this error "Closing connection: Internal Server Exception" when calling set_plugin_data.

I tried to call the function with a wrong key-name and/or wrong plugin-id, but this didn't change anything.

The log with debug enabled looks like:

Dec 09 23:44:01 duetpi DuetControlServer[725]: [debug] IPC#62: Granting full DSF permissions to external plugin
Dec 09 23:44:01 duetpi DuetControlServer[725]: [debug] Command processor added for IPC#62
Dec 09 23:44:01 duetpi DuetControlServer[725]: [debug] IPC#62: Received command WriteMessage
Dec 09 23:44:01 duetpi DuetControlServer[725]: [info] [IOExample]: IO [auto:True; inputs:True,False,False,True; outputs:True,False,False,False]
Dec 09 23:44:01 duetpi DuetControlServer[725]: [debug] Got new connection IPC#63, checking permissions...
Dec 09 23:44:01 duetpi DuetControlServer[725]: [debug] IPC#63: Granting full DSF permissions to external plugin
Dec 09 23:44:01 duetpi DuetControlServer[725]: [debug] IPC#62: Connection closed
Dec 09 23:44:01 duetpi DuetControlServer[725]: [debug] Command processor added for IPC#63
Dec 09 23:44:01 duetpi DuetControlServer[725]: [debug] IPC#63: Received command WriteMessage
Dec 09 23:44:01 duetpi DuetControlServer[725]: [info] [IOExample]: Closing connection:  Internal Server Exception
Dec 09 23:44:01 duetpi DuetControlServer[725]: [debug] IPC#63: Connection closed
Dec 09 23:44:01 duetpi DuetPluginService[1702]: [info] Plugin IOExample: Process has been stopped with exit code 0

Calling the function ('set_plugin_data("IOExample", "output0", 1)') with a non-string value gives a different error:
"Closing connection: value must be a string"

Anything else I can test ... ?

chrishamm

@rero The dsf-python library for v3.6 is being overhauled, because unfortunately it didn't fully adhere to the IPC protocol standard. A while ago I made a DSF plugin in C# for DSF 3.5 and that worked well with SetPluginData but I'm going to test it again to be sure.

Version 3.5.4 should work as expected, but note that I've never tested the Python set_plugin_data function myself.

AndyE3D

@rero Hi, these errors should be fixed in dsf-python 3.6.0-b2.post3. Let me know if you have any further issues

AndyE3D

@rero regarding the issue where the data variables disappear from the OM, in my testing on 3.6-b2 the variables are still accessible with meta gcode but are not being displayed by the OM plugin correctly. This is likely a DWC issue which @chrishamm is looking into.

You can test if the variables still exist with

echo {plugins.IOExample.data.output0}
echo {plugins.IOExample.data.output1}
echo {plugins.IOExample.data.output2}
echo {plugins.IOExample.data.output3}

chrishamm

@rero I could confirm that there is a problem in DWC preventing the correct display of updated plugin data even though it's correct in DSF. I've got a fix ready for the next DWC beta. Thanks for reporting this!

rero

@AndyE3D @chrishamm thanks for the investigations and the fixes.

Did a quick test, stayed with 3.6.0-beta2 and updated dsy-python to 3.6.0-b2.post3:
-> No exception/exit anymore
-> String-values are correctly set via set_plugin_data
-> Object model plugin variables disappear (only last one modified is visible), accessing them via 'echo ..." works
Reloading the OM-plugin page via browser reload also brings back all values.

Will test tomorrow if using non-string values also works for me and also test 3.5.4 again.

Thanks for your help, have a good evening!

rero

Final tests:

For 3.6.0-beta2(.post3) all relevant data-types (float,int,bool,string) worked as expected.

For 3.5.4 with dsf-python-3.5.0 setting string-data and accessing it via "echo ..." also works.

So issue solved for me - merci!
Thx @all for their support to answer questions and find/solve issues!