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