Posts made by rero

@jay_s_uk thx a lot!

You are absolutely right.
And to my shame: got this information already last week, and forgot about it ..

I am trying to offset my axes-limits with machine-dependant values.

So when I am trying to execute M208 with two expressions separated with a ':', I get an error:
"M208: Z axis maximum must be greater than minimum"

var offset_z = 1.0
M208 Z{-10+var.offset_z}:{136+var.offset_z}

Separating min-/max-values works with no problems

var offset_z = 1.0
M208 Z{136+var.offset_z} S0
M208 Z{-10+var.offset_z} S1

Is this behaviour to be expected?

Want to give it a try asap for our project (at least within the next weeks).

Just one question @chrishamm reg. build of DSF with Visual Studio 2022: should this work out of box or do you have any updated build-instructions?
I just tried rc1 and it gave same errors as with other 3.6-betas before: the new SourceGenerator seems to be missing in some projects and therefore the code it should automatically create isn't available and compilation fails.

Regards,
Reiner

@chrishamm thanks for checking the issue.

One thing I observed today: a similar/identical(?) problem exists also with ObjectModel.Global: this ModelDictionary also doesn't contain any entry ... while the variables are available via DWC/ObjectModel-Plugin.

I tried 3.6-beta4 last week, but was not able to compile it - there were some issues with your new SourceGenerator, I will try again when I have more time / finished the basic stuff with DSF/RRF 3.5.

@jay_s_uk thanks for pointing out!

"Can't see the forest for the trees" ...

@dwuk great find!

Just tried it on my test-setup and it works as intended.
Only complaint: no information about the upcoming tool-number in the tpre.g macro.
But for my concrete needs I should be able to move existing tpre-code to tpost.

-> Maybe someone can add this information to https://docs.duet3d.com/User_manual/Tuning/Tool_changing ?

Another idea: having another tXXX-macro which is executed in case a tool has been already selected previously (e.g. to probe a current milling-tool again).

@davidjryan if your assumption is correct, two instances/connections/channels of DWC via different browsers should have equal logs.
So if you run a command through the "Send"-function of DWC, the (error-)message will/should be shown everywhere ...

For me that is not the case: every command performed/executed directly reports only to the source-channel which send the command.

For your control-app: what is the answer from the DCS if you perform your test-command?
Like in https://github.com/Duet3D/dsf-python/blob/v3.6-dev/examples/send_simple_code.py ?

If you app is the only controlling-instance, this functionality should be suitable for you ...

Good evening,

when using duet-boards on CNC-Mills (or other devices != 3D Printer) it is required to create/write a set of tool-change macros for each tool(-position):

tfree1.g, tpre1.g, tpost1.g, tfree2.g, tpre2.g, tpost2.g, and so on and so forth ...

For my current project I created these files, but they contain just a single line to call a generic, parametrized version:

; tfree1.g calls my tool-change macro
M98 P"tfree.g" X1

It would be nice if such a mechanism would be supported out of the box inside RRF.
And I could get rid of 57 macros (19 tools) in my sys-folder

@davidjryan sorry I was mislead by your thread-subject and did not carefully read your full post.

I assume you want to check the messages-member of the ObjectModel (see https://github.com/Duet3D/dsf-python/blob/v3.6-dev/src/dsf/object_model/object_model.py and https://github.com/Duet3D/dsf-python/blob/v3.6-dev/src/dsf/object_model/messages/messages.py for details).

I did a quick test with my c#-application and M118- and Plugin-Output arrived successfully ...

Check also https://github.com/Duet3D/dsf-python/blob/v3.6-dev/examples/subscribe_object_model.py - this example shows how to access the ObjectModel.

HTH

PS: Link-reputation achieved!

A quick update: did a test with my concrete macros on 3.6beta4 and the same delay/pause occured.

Need to fiddle around more with the code to understand which combination/code-part actually is causing the delay. More to test ...

@davidjryan there is a perfect example in the dsf python-bindings:
examples -> custom_m_codes.py

(Sry, don't have the reputation (!) to post links in this forum)

@chrishamm I am using DSF version 3.5.4

@chrishamm

I am using a SubcribeConnection to access/update the ObjectModel:

// connect and retrieve first complete ObjectModel
await _subscriptionConnection.Connect(SubscriptionMode.Patch);
_objectModel = await _subscriptionConnection.GetObjectModel();

// periodically get ObjectModel-changes
while (true)
{
  using JsonDocument wModelPatch = await _subscriptionConnection.GetObjectModelPatch();
  _objectModel?.UpdateFromJson(wModelPatch.RootElement);
}

The code to access the Plugin-data, looks like this:

if (_modelObserver.ObjectModel is not null)
{
  _plugin = _modelObserver.ObjectModel.Plugins["IOExample"];
  if (_plugin is not null) 
  {
    //iterate over data-keys
    foreach (String key in _plugin.Data.Keys)
    {
      PluginInfo += $"Data/Json-Property '{key}': '{_plugin.Data[key]}'";
    }
  }
}

This works as expected, but the Plugin.Data member is empty in this case (while I can see the Data-variables in the DWC-ObjectModel-Plugin).

Good evening,

after solving my previous issue with populating the ObjectModel with Plugin-related data, I am now facing a related situation.

I am developing a C#-based HMI-Application to control the CNC-machine and would like to show/present different IOs of my Plugin (which interfaces the IO-Board).

If I got the documentation right, I should use ObjectModel.Plugins["MyPlugin"].Data to read the Plugin-Data.
In my case this Dictionary is empty, although I have 8 IOs/Variables registered with the Plugin itself (and visible in the DWC-Objectmodel Plugin).

Am I missing something here (doc says something about 'registration of Variables before using SetPluginData', but I want to read existing vars)?

Any hint/help is appreciated

Regards,
Reiner

@T3P3Tony thanks for your response and check.

I will test this when I am back in front of the machine next week. Just ordered some fast SD-cards. so I can upgrade without any fear to break something

I will also try to execute the tool-macro(s) manually instead of being called through the implicit tpre/tpost/tfree-mechanism ...

Thx && have a good evening!

Good evening,

following situation with a Duet6HC-Board in SBC-Mode connected to a RPI 5 (FW/DSF v3.5.4):

When I run tool-change macros and reach a certain depth of nested macros, I get a delay of ~4 secs after executing the 'deepest'/innermost macro.

The macro-calls look like this:

Any tool command via console (or NC file):
-> tfree_1.g
-> tool_free.g (my generic tool-command)
-> system_vars.g (set/updates a bunch of global variables)
-> special_system_var.g (set a single global variable)

When I execute special_system_var.g the system pauses for some seconds. From the log I can estimate the delay: ~4 seconds.

I doesn't matter if this macro contains any code; even if it's empty the pause occurs.

If I remove this macro(-level) and replace the M98-call with the macro-content everything works as expected.

I checked if this is a generic issue with nested macros: I called up to 6 nested macros without an issue. I also tested these macros (just some echo-stuff and the M98 for the next level) within a system tool-change-macro and also no problem.
So the issue is related to the nesting-depth and my concrete tool-macros.

I can easily find a workaround for this, but it should be helpful to understand what happens here.

Anyone any idea?

Thanks and regards,
Reiner

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!

@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!

@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 ... ?

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?