@dc42 Installed the beta, everything is fine!
M409 k"move.axes[]" f"f"
{
"key": "move.axes[]",
"flags": "f",
"result": [
{
"machinePosition": 2.652,
"userPosition": 0.102
},
{
"machinePosition": 5.511,
"userPosition": 0.102
},
{
"machinePosition": 180.17,
"userPosition": -0.03
}
],
"next": 0
}
Many Thanks!
@dc42 Thanks, so I will pursue with a full json solution!!
@dc42 I bought my 1st 3D printer 10 years ago, a Fabtotum.
I bought 2 years later a Big Box from E3D.
In the mean time, I manufactured countless parts
Special hinges for mosquito net to equip my 12 windows
Various supports for phone, pc
Dozens of RPI enclosures, including caméras rpi0
Repair parts for a dishwashing machine.
Fixtures for connecting various feather boards with test pins.
Complete Fabtotum rework, including 6 new print heads with various extruders, last one is a orbiter with piezo packed in 42mm square envelope...
Big Box rework, some new parts, including duet2 supports, panel due box, cleaning system
Letters for my grand child's
Different lamps, including a pair of candle imitated neopixel ones
Currently refurbishing a milling machine with multiple 3d parts: display, supports, panels....
Looking for buy/build a new printer and discard old one.
Hi,
I am in the process of developing a new CNC pendant for a very old CAMM3 Roland machine, using the original 3 jogs panels which I appreciate very much.
For this, I use a PICO2, FreeRTOS and coreJSON to provide the glue between the origianl panel and a DUET6 HC .
I noticed that when I issue M114, I receive a data result with 3 digit accuracy for coordinates, both machine and user.
Since the answer ( RRF 3.6.0-beta.2+3) is packed in a json string, I try to simplify my request using a M409 , that would give me more information on the axes within a single IO serial transaction with duet. (Machine coords, User coords, homed, ....
Examples:
X:-12.500 Y:-22.000 Z:169.905 E:0.000 Count 60001 44801 226484 Machine 37.500 28.000 169.905 Bed comp 0.000 -> using M114
{"key":"move.axes[2].machinePosition","flags":"a0","result":170} -> using M409
My understanding from M409 documentation is that limiting buffer size on RRF force to split the answer in multiple chunks (a0 flag) when using k"move.axes[] for instance.
This is not the case for me since I issue
M409 k"move.axes[2].machinePosition" for getting the value.
this should answer 169.905, but it spits 170.
BTW DWC also displays 170, which is not really accurate....
Question: Is there any way to obtain the full resolution using M409 or do I have to use M114 with a ugly string scanning?
Many thanks
@NineMile I have seen this thread , did not find him again , however this was in a corner of my memory for a while.
I am refurbishing a Roland CAMM 3 trying to keep the control panel with 3 separate x y z jogs.
Will test happily your work as soon the old panel is connected to the Duet6HC through a custom made board I am working on.
@dc42 I don't plan to, I just need to calculate and adjust the rpm from a tick sensor on spindle start.
I use a biffy BLDC that transmit movement to an ER16 spindle through a set of GT2 pulleys.
@NineMile Nothing prevent M568 to be treated like M3...4.. 5, since the spindle number should be used the same way.
@dc42 I have a suggestion for making things much simpler and not further complicating RRF GCODE.
We basically need M3, M4 and M5 commands to handle the spindle at the GCODE level, plus M950 to init the corresponding io.
As far as I understand, these commands, handle a spindle created with M950, which, in turn make the assumption we drive the spindle by pwm through a given pin. Nothing is related to modbus nor serial link in M950. This command is somewhat complex, because you handle many different peripherals (led strip,PWM, servo, temp, etc), everything that can be handled by DUET standard io at the hardware level.
As you said, there is little chance that you can support each and every modbus motor/controller on the market, and this should be the case, I think the program memory should be filled by unused code.
On the other hand, a GCODE command not implemented in RRF will call a macro of the same name ( e.g. M1000.g)
We could use a M3.1 M4.1 M5.1 to handle the modbus specific, but this would not be standard and would need some post processing.
I suggest that RRF, for limited control codes (M3,M4,M5...), instead of handling what is defined by M950, just call corresponding macros when instructed by M950.
This way, M3,M4,M5 would be handled by the user, it's the user's responsibility to handle all the modbus specifics inside these macros.
Introduce a parameter M (0 or 1, default 0) in M950 that tells, for the corresponding spindle (R parameter), to call M3_R.g, M4_R.g, M5_R.g R being the spindle number. To avoid a race condition, M3,M4,M5 commands called from inside these macros should not be possible, either raise an error or just do nothing.
modbus complexity would then be handled by a macro.
you can extend this to other devices (fans, heater, leds,....) managed through serial, spi or I2C devices.
M3 P1 S1000 would call the macro M3_1.g with parameter S=1000 exactly like M98 P"M3_1.g" S1000.
M950 with the M1 and R1 would also call a macro M950_1.g that would init the serial link, maybe check the modbus status to make sure it will work.
You could expand this to all codes related to M950 for handling special cases not handled by DUET ios.
I think it would solve the issues I have seen on the forum, included mine without introducing specific GCODES.
@dc42 I did change the power to 5V and this is OK now.
Many thanks
@dc42 Saleae logic is connected to the io1 pins.
Converter is powered by DUET 3.3v line.
Will test 5v supply to the converter and report.
Thanks
@dc42 Here is a complete test sequence
M260.4 P2 A1 B{0x06,0x80,0x05,0xdc,0x05} R5 Note:works with coma separating bytes, not with ':' as separator
The message is processed, then spindle speed is set correct accordingly.
Note the glitches in the yellow trace during device answer, they are not systematic, but frequent.
M260.1 P2 A1 F6 R{0x8005} B{0xdc05}
Message is processed, then spindle speed is set correct accordingly.
Answering time is randomly different, according to mpdbus specs..
Note the glitches on DUET's yellow trace.
In both cases, same error
I can live with that until further notice, since errors only pollute the UI and this is workable for now.
If you have more test sequences in mind, will be happy to help with my setup:
1-Stepperonline BLD-530 S coupled to a biffy BLDC
2-Waveshare TTL To RS485 (C) Galvanic Isolated Converter, Half-Duplex Communication, Lightningproof & Anti-Surge, Multi-Isolation Protection
SKU: 27479
Part Number: TTL TO RS485 (C)
3-DUET 6HC under 48V power supply in CNC mode
Thanks for help
@droftarts Works now writing a single register with betaversion from @dc41 excepts that it always say
"Error: M260.1: no or bad response from Modbus device"
DUET issues a single register write
device's answer in green
These answers are analyzed by Saleae Logic analyzer.
The only difference is the device seem to answers with a larger stop bit, while DUET is perfectly
OK on timing.
Since I cannot dig more into the error above, I cannot determine what is wrong or if this is just due to beta version.
DUET3 6HC 3.6.0-beta.2 CNC mode
Trying to communicate with a StepperOnline BLD-530S BLDC Motor controller in modbus (spindle).
Try to send raw modbus message as indicated in the BLD-530S user manual, get this answer....
Error: M260.4: Command is not supported
260.1 works but not understandable by BLD-530-S (reason why I try M260.4)
Any idea of availability? 3.6.0-beta.3? official release? when?
Many thanks
Kind Regards
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
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
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