Posts made by raykholo

I would like to make a minor usability improvement for myself, which is that when a print finishes, I would like the PanelDue to go from the print "Status" tab over to the "Control" tab so that I can interact with the machine. I was wondering if there was a gCode command that would tell the PanelDue to do this, or perhaps there is some other method or a setting to achieve this result?
It also made me wonder if there are other gCode commands that can tell the PanelDue things like "do this" or "show this".

@deckingman been a long time, hope you are doing well. Watched a lot of your more recent videos last week to get caught up on "fun crazy machines".

Thanks for that link. My search didn't find it, likely because they didn't say "binary" in the title.

Hi folks,

In the latest Prusa blog update, they mention that PrusaSlicer 2.7 will have support for a more efficient binary GCode file format.

You can read about it here:
https://blog.prusa3d.com/update-original-prusa-xl-input-shaper_83744/
by going to the section titled Slicer packed with tons of new features – introducing .BGCODE, SVG support

The library is available here: https://github.com/prusa3d/libbgcode

I am wondering if this is something that the Duets could be made to handle. The appeal would be faster upload speeds of large files.

I am currently getting sub 1-meg speeds uploading files to my Duet 2 Ethernet. I'm going to check the suggestions in this thread after my long print finishes. https://forum.duet3d.com/topic/29825/slow-project-upload-speeds-using-dwc

It's not horrible, I just have the bed pre-heating while the file uploads, but for large prints we might be looking at up to a few minutes of upload time.

The Duet 3 with SBC, even on WiFi, has substantially faster upload speeds, but:
a) it is not economically feasible to upgrade all of my Duet2 machines to a Duet 3 + Pi, and
b) I am hoping that all my Duet 2 Wifi/ Ethernet based boards/ machines have a lot of life left in them.

Having a couple extra Duet 3 Mainboards sounds like a fun problem to have

Just seeing this now. Couldn't have said it better than @poofjunior did. He helped me with a whole bunch of seemingly random parts of bigger projects since 2+ years ago, great guy, I don't have the words.

David,

It sounds like OP wants to use the 6 high power stepper drivers on the Duet 3 for other purposes, and is essentially asking whether he can tap a stepstick into some IO pins directly on the Duet 3 Mainboard.

You are saying that this is not possible, and that you have to use the 6 onboard drivers and that a 3HC (or 1LC) expansion board is the only way to do more stepper drivers - is my understanding correct?

This is also of interest to me.

@Danal the active development appears to be happening in branch v3.01-dev, not dev where that file does not exist.

I have started reading the contents of:

https://github.com/dc42/RepRapFirmware/tree/v3.01-dev/src/CAN

and:

https://github.com/dc42/Duet3Expansion/tree/master/src/CAN

I agree that having to use a-b*floor(a/b) for remainder hurts readability, especially when inside complex expressions. Please please please have a dedicated mod operation. Either syntax of mod(a,b) or a%b is completely fine.

For the quotient, rounding is surely another option and floor(a,b) would be fine for our purposes.

Also, please note that I used syntax of function (a,b) and not function (a/b) above. I have usually seen it as comma separated parameters and I am concerned that using / would confuse the system into thinking it is division inside the function.

Thank you very much for the consideration.

Hi David,

Would it be possible to have the mathematical operations of "Quotient" (divide without remainder) and Modulo (just the remainder)? I did not see any reference to these in the Meta Commands documentation.

I want to build a filament changer (MMU2 style to feed different filament types/ colors) on top of a tool changer (grab different nozzle sizes) so that any combination of filament/ color and nozzle size is possible.

In an example of 3 tools (say a 0.25, 0.4, and 0.8 volcano nozzle sizes) and 5 filament colors, we have 15 combinations to resolve. I would use the existing T# functionality to handle tool changing, and would write a similar construct in Macros to handle the filament color changer.

I would use a Macro to resolve the 15 possible combinations into the existing T# commands to select tool, and Macros would handle the filament switching commands.

As you can see in the spreadsheet image here, we would need a Quotient and Modulo operation to do this. Quotient is Tool #, Modulo is Filament Color #.

Thanks!

Yes, I was using the button send as the simple example of "yes, this should be straightforward to replicate". I just checked how a defined macro button works, and it does indeed send an M98 command with its name "Test1" so that's fine.

rr_gcode?gcode=M98%20P%220%3A%2Fmacros%2FTest%201%22

I was thinking about making other UI elements (dropdowns, sliders, etc...), where it would have to be written into HTML. So yeah, M98 seems to be the proper way to do this.

Perhaps... you are asking "Does the new conditional/variables stuff include having macros take arguments and return results?" I'm investigating that same question myself.

For getting data back, yes, I would like Macros to be able to return data that the DWC can use to update custom UI elements (show values in text field, change a slider position, all the things that already happen with temps and so on).

Right now, I only see an echo command that writes a message to console: https://duet3d.dozuki.com/Wiki/GCode_Meta_Commands#Section_Echo_command

I do not know that the webpage would be able to parse console messages to see if it finds data to update the UI. A real way to return data would be preferable.

I'm not sure if the data might need to persist somewhere for things to work well, which is why I brought up sticking it in the object model/ lastStatusResponse JSON object.

Hi folks,

I'm exploring some ideas for an advanced 3D Printer project, am very excited for the new variables and conditional logic functionality which should make things a lot easier, and would appreciate some feedback on these things:

Adding controls to DWC:
If we wanted to have a new button, we could make it in HTML, bind it to JS function, and have that use sendGCode to trigger a respective Macro for that button.

As an example: Button1 could trigger sendGCode("M98 P"button1script.g"");
I'm sure there is some specific syntax needed to deal with the quotes inside quotes, but does this make sense?

Getting data back from the Duet board to DWC to update elements with info. This is where it gets more interesting...
As best as I can tell, things like temperatures, tools, etc... are in DWC as lastStatusResponse, and the UI elements are updated using that. I haven't looked at how this is done on the firmware side yet, so please forgive any oversights and point me to any relevant code that would put me on the right track.

I would prefer not to have to modify the RRF firmware in order to add functionality that sends data back to DWC. It would be much more preferable if Macros could have the ability to send data back, either directly, or through the model behind lastStatusResponse.

The way I could see this happening:

• Execute a command in config.g for "add this new field to the board's status object".

• In a Macro, a command can be used to update the value of that field with new data.

EDIT: Does what I am describing here relate to the new RRF3.1 Object Model? Is that what will be getting sent back to DWC for the status of heater/ selected tool/ etc? If so, would you allow for custom keys to be added to the object, whose values can be updated via gCode, as described above?

Would love to hear your thoughts on this.

Thanks,
Ray

@phaedrux said in Laser power adjustment/speed:

I'm not sure if that comment that the Duet doesn't support G1 S moves to control the laser is accurate anymore as of firmware 2.02

Oh cool! I'm not up to date on Duet/ RRF since firmware 2.0 came out. So then the question will become how well RepRapFirmware handles these lines such as G1 X0.1 S0.6 F6000 (that's Smoothieware syntax, or in RRF case S255) when receiving several thousands of them a second for image rastering.

I don't know what the performance of that will be like.

Speeds were slow when we tested it with the "Marlin-resembling" previous syntax, and to be clear, that was the source of my comments in the LightBurn Forum.

Is there somewhere I can read about the hardware revisions? I am curious as to what changes were made with the latest Duet v1.04 and the DueX expansion board.

@dc42 said in Might have finally killed a DuetWifi:

There was one user who posted on this forum about replacing all the blown chips in this situation, but he had to replace almost all the chips on the board, including the stepper drivers AFAIR.

I might enjoy that rework job, if you want to donate such a dead board for "science"

@DjDemonD

@dc42

Smoothieware gives the cleanest corners when cutting we have seen. To the best of my knowledge it is handling the calculations for acceleration, deceleration, speed, and respective laser power pwm on each step generated.

The PWM rate is proportional to the speed, so the power to the tube is, but the CO2 tube doesn't respond in a linear way, so it's not perfect.

@dc42 said in Duet hardware actually makes it into Thomas Salanderer's videos:

All stepper motor drivers include flyback diodes.

Can you elaborate on this? I have not seen any flyback diodes on the Duet Wifi nor on the Maestro anywhere near the motor drivers.
So is this something that is internal on the TMC2660? What about the TMC2224?

I ask because we did manage to kill a TMC2224 by the motor cable coming unplugged while energized on a recent prototype board. I would appreciate any tips on how to make the drivers more robust in this scenario.

@dc42

Regarding #4, can you confirm that Marlin, Smoothieware and grbl all carry over the S value from one G1 command to the next as you describe? In which case the S parameter on a G1 command behaves exactly the same as a M3 command before that G1 command would.

To the best of my knowledge Marlin does not do G1 X10 S0.6, it does not even discern between G0 and G1. So in Marlin M106 S255 followed by a number of G0/ G1 move commands would all abide by that power until another M106 was called.

In Smoothie and Grbl, the S does indeed carry over as from my example of G1 X10 F600 S0.8 followed by G1 X20, the second command would operate at the same feed and power value.

Smoothie and GRBL differ regarding M3 and I am concerned that neither of them is what it sounds like you are describing.
In Smoothie, M3 has nothing to do with laser. It is simply yet another gcode that can be configured to control a switch or a spindle module.... But if you simply send a G1 X10 F600 S0.8 the laser will run, no previous M3 required. But we put an M3 at the start of the job to be safe, and an M5 at the end.

In GRBL, please check here: https://github.com/gnea/grbl/wiki/Grbl-v1.1-Laser-Mode

In short, it is a single M3/ M4 (per the link M4 is dynamic laser mode for better variable laser power) for better at the start of the job, and an M5 at the end of the job.

In no case do we want an M3 at the beginning and M5 at the end of every G1 line, that would clutter the gcode.

The Amazon link for the brush doesn't work.

@dc42

1. I like it.
2. This is certainly one of several reasonable ways to handle it.
3. Perfect.
4. Important point here: when we have G1 X10 F600 S0.8 followed by G1 X20, the second command would operate at the same feed and power value. Both feedrate and the laser power aka "spindle speed" must be modal. This is important because in the gCode we are working with there are no M3/ M5's at all, just G0 and G1 lines. From a cursory reading, I am not sure if conflicts might arise from listening to both M3 S values and G1 S values. Thoughts?
5. This certainly extends flexibility and might even solve the concern of compatibility with legacy control softwares.

Hi Folks,

We've been discussing how to better implement Laser (and CNC would be very similar) support in RepRapFirmware and would like to get your thoughts on a few gCode things:

The current sending approach I am seeing for setting laser power (interchange with spindle speed) in RRF is the "set the power of the fan with M106" so your gCode looks like this:

M106 S100
G1 X0.1
possibly M107, or if doing continuous raster line segments might be able to continue the raster line with another set of M106 and G1.

This most closely how Marlin does it.

Meanwhile, in Smoothie and Grbl, we can do:

G1 X0.1 S100 where S indicates a laser power range (Grbl is 0-1000, Smoothie is 0-1).

Given that the S parameter is used in almost all existing CNC and Laser driving software because S is the defacto designator for Spindle Speed… but RRF uses the S word to set endstop sensing...

We're down to 2 options I would like to present to you and get your opinions and vote on:

1. Use a different letter instead of S in the G1 line. Conveniently, L is available. So we could do G1 X0.1 L100 and any actively developed Laser/ CNC software could adjust/ make an RRF profile and all would be good, but any existing/ "legacy" software that is stuck outputting S would need to be post processed.

2. When the machine is put into Laser mode using M452, we would change the meaning of S in G1 moves to be laser PWM. So you would need to use the alternative parameter letter when doing special G1 moves in homing and tool change files. This allows legacy support and immediately supports more software out of the gate, but causes the concerns with S interfering with the homing scripts, and further potential overlap concern with a combo machine - either a 3DP/ Laser combined, or a multi toolhead machine like the new E3D announcement.

All thoughts welcome.

Thanks,
Ray