Bought a Fabtotum on Kickstarter, received it in 2015, and got my 3D Printing training with it. Good training, since it learned me by practice all the mistakes to avoid as a user, but also all those to avoid as a designer.
For instance, it stopped using it after the ribbon broke due to trailing on the bed and colliding with printing part. Collecting dust since 2 years since.

I decided recently to give it a rebirth by changing almost everything except COREXY mechanic, the most valuable thing in FT in my view.

Removed all guts, including the RPI and heads, printed parts for X end stop, new bowden E3D V6 / TITAN based with most advanced parts, and it worked almost at the 1st run.
I will now use this as a test platform for new heads, water cooled, TITAN direct drive and more.

@fcwilt Yes, I print tiny parts ( custom gears and connectors), and I need minimal entry points on my objects to allow best external mechanical interface possible.

Therefore I need to purge my nozzle between each part to ensure identical start conditions.

And since I need many parts, I stuff my printing bed with as much as possible parts.

Quick questions regarding 3.6.0 Beta.2 on a DUET6HC

Are the M260.1/M260.2 commands available on this beta version as stated in the doc ?

If YES: May I use simulateously
1-DuetWebControl through wifi for console operation
2-io0 serial IO connected t to a custom CNC-Pendant like board
3-io1 serial IO connected to an adapter talking to a modbus device (BLDC controller)

io0:I would send gcode command (M105, M409.... GXXX) through io0

io1:General idea is to keep spindle section electically isolated from DUET to avoid mass loops, since currents (both DUET 48V with NEMA23) and 400W BLDC are pretty high and cabling is quite complex, while having complete gcode control over BLDC (speed, CW/CCW, stall ....)

What is the max baud rate for each interface when used ?

is there any bottleneck/precaution to use this somewhat serial IO demanding configuration?

Of course I will carefully test all this and report any issue and/or success.

If NO or partially available, how long will I have to wait (project planning, I have no killing deadline ) ?

Many thanks for your help

@droftarts

Thanks again for your answer.

In fact I misunderstood the doc, since I use for years DUET2 & Octoprint and I thought the status messages seen on Octoprint were just a normal DUET output.

My mistake.

I understand M116 & M117 are just what I need for

@droftarts

In fact, this project inspired me from the very beginning.

I envision the same kind of project, but I would like to avoid connecting to PanelDue pins, rather using the usb cdc that is used by Octopi for instance.

Reason is mainly cabling, I would like to avoid pin connection through the Pandeldue, especially because I am not sure to put a panel due, rather using either a direct connection through internet or SPI and/or storing CNC files in the on board SD card. I plan to desing an interface board with a PICO2 that will animate both jog panel and LED display for axes.
This board will send M & G commands to the DUET according to buttons press, jog rotation and more.

Furthermore the panel due cable is somewhat limited in length for obvious reasons,

My PNC-3000 is equipped with NEMA23 motors and a spindle activated with a 400W NLDC, so the noise immunity is particularly important. Interface board will be located very close to the DUET for this reason and cabling will be especially clean of noise.

I also think evaluate RPI4 as an SBC intermediate, but this is not my priority now.

Thanks for the advice.

Planning to upgrade a ROLAND CAMM-PNC3000 ( Z80 based cpu and TTL levels everywhere)
BUT
I would like to keep the very useful command panel (3 axes simultaneous jogs) and if possible the LED display. (A sort of "lipstick on bulldog").

For this, I need to emulate the old IO Z80 CPU interaction, then according to buttons and jogs hits, send G commands to DUET6HC i bought to animate this NEMA 23 mechanic ( 48V based).

I am evaluating the PICO 2 with a FreeRTOS base OS to keep all chances of restoring the real time tick action of jogs and display on axis I previously experienced with the old.

Roland original design is very straightforward: the tick action on the jog fires directly the stepper motor driver through the same wire...simple and efficient.
I will also possibly (but not sure for keeping original CAMM aspect) add a Paneldue to this setup.

I have seen the interesting setup from hurzhurs you reproduced in the DUET3 doc for connecting the CNCPendant to the panel due.

Of course I can connect directly the PICO to the DUET using the Paneldue connector and io_0 pins.

I also evaluate the possibility to connect my setup simply through the USB C plug.

I read through the firmware doc the status messages are constantly sent through this interface. Of course these sequences take some bandwidth and this is obviously not desirable.

So it leads to following questions :

Are the same messages sent through the Paneldue io pins ?
Is there a way to suppress those messages (MXXXX ???) of course I would avoid forking reprap

Is there a way to setup the serial interface (speed and parity) ??
Are those messages also routed through Paneldue ?

Are the Paneldue pins Din Dout a a real passthrough pin to pin?
Is the SPI interface also an option ?

Would you recommend any other option ?

Many thanks for your help

@dc42 Many thanks for advice, will keep u posted when done.

@Phaedrux I am thinking about current, both peak and hold, since it's a CNC, not a 3D printer.

I want to rebuild a ROLAND CAMM3 machine, which seems to have 3xNEMA17 X Y Z.

Do I need a DUET3 6HC, eventually associate 2 drivers for one stepper or a DUET 6XD and some external stepper drivers like DM542T?

Many thanks for advice

@dc42 So I solved the problem by putting a simple macro that shows up on Panel Due main page.
This toggles the variable that control the cooling. Then I can modify it while a macro is running in a loop.

Regarding daemon.g, I think user should have control on the 10 sec delay. I understand the reason why this is done that way, but this greatly limit the usability of this interesing functionality.

Many thanks again for help

@dc42 Yes, but it will fire only at 10 sec interval, plus the G4 parameter, plus more, which is far too long.
I understand the reason why you stretched this delay, but in my case, I just scan the print area with the fan running at100%, nothing to do with print quality. BTW it cools the part, dual extruders and bed 40% quicker on my bigbox.

For instance, a G4 S4 will end up with 4 +10 minimal delay. Since I cannot change the 10 sec delay, it is useless. Would need as low as 100 ms to be workable for my use case.

BUT it works when I use the DWC console (set global.cool_part=false) while printing through Octoprint on a RPI 4. There is hope there, except I have to switch from Octoprint to DWC, what I try to avoid.
I don't dislike DWC, but I use mainly the PanelDue rather than the web interface once launched the print through OCTOAPP on mobile, and setting up a global variable through the panel is not very easy and I don't see how I can do it through octoapp.

Maybe I miss something on panel due ( custom button with a meta command on main page possible? )

Many thanks

@cosmowave Thanks for the tip, but I cannot wait 10 Sec between action not put a loop inside the daemon.g code, since my code is scanning a a certain rate to cool down, and I need also to deactivate the daemon.g from the outside => more global variables..... Since this 10 sec is hard coded, I'm stuck....