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

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

@jay_s_uk thx a lot!

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

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

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

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

@jay_s_uk thanks for pointing out!

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

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