Firmware package 3.2beta1 released

chrishamm

I've updated the DSF and DWC releases and apt packages once again. The work-around as mentioned before should be no longer required.

For Duets in standalone mode there is a new DWC version available, too, which can be obtained either from the RRF or DWC release page.

arhi

@chrishamm said in Firmware package 3.2beta1 released:

@oozeBot You need to connect to your pi via SSH, then run

sudo curl https://pkg.duet3d.com/duet3d-unstable.list -o /etc/apt/sources.list.d/duet3d.list
sudo apt-get update
sudo apt-get upgrade
sudo curl https://pkg.duet3d.com/duetcontrolserver.service -o /usr/lib/systemd/system/duetcontrolserver.service
sudo systemctl daemon-reload

Wait a few seconds and you should be on 3.2-b1.

the duet2eth with special firmware links to this same duet3d controlserver or there's a separate one ?

A Former User

@arhi DSF om the SBC is the same

devpeeps

installed

arhi

@dc42 I know I'm being PITA but I have to and I apologize

It is impossible to figure out what are the branches of each project required to make a certain build. The BuildInstructions.md is not very up2date. So it would be cool if you could, for e.g. in these forum release posts, add info on what branch of each project goes into this release :). Ideally adding a same TAG as release on each product would be awesome

tristanryerparke

what is the nature of the continuous rotation feature you added? Does it actually do shortest-distance calculation or does it just remove limits?
Thanks

dc42

It does shortest distance calculation on G0 moves. Caution, it's not been tested separately in this release, although the underlying code is known to work for SCARA kinematics in previous releases.

tristanryerparke

Thanks. Would it be possible to add an option in the 3.2 release for this to apply to g1 moves as well?

dc42

@tristanryerparke said in Firmware package 3.2beta1 released:

Thanks. Would it be possible to add an option in the 3.2 release for this to apply to g1 moves as well?

G1 moves are normally extruding moves, laser cutting/engraving or CNC cutting moves, so it would be inappropriate. It's only for G0 moves that the planner has the freedom to decide how to reach the target position, subject to not allowing Z to get any lower than a straight-line move would.

tristanryerparke

Ok, I guess for my application I can just momentarily change the max speed of the machine to achieve a slow, shortest-distance move.
You don't think I could add the g1 functionality in a custom build? It is just that this new feature has eliminated the need for a post-processor that I wrote and it would be nice to fully eliminate the need for that. Or could it be just an option that is not default?

dc42

@tristanryerparke said in Firmware package 3.2beta1 released:

Ok, I guess for my application I can just momentarily change the max speed of the machine to achieve a slow, shortest-distance move.
You don't think I could add the g1 functionality in a custom build? It is just that this new feature has eliminated the need for a post-processor that I wrote and it would be nice to fully eliminate the need for that. Or could it be just an option that is not default?

What's the application, and what program is generating the GCode for it?

tristanryerparke

@dc42 Five axis painting machine and foam milling machine, my senior work in college. Attached is an image and video of the plastic prototype making a test painting of line-based moves if you are interested (it still isn't working how I want it to but getting there).

Essentially it has a continuous rotation axis that rotates parallel to the z. So certain circular moves with the brush following tangent end up sending the head on an "unnecessary" rotation which is due to the IK sending it a G0 A1 when it is at position A355. All GCode being generated in python and rhino/grasshopper, and right now I have a post processor checking for this extra rotation and sending a G92 to set A to -5 before the above mentioned G0 Move. This creates delays in the movement and can get messy.

Duet 2 and rrf have been the key drivers behind this machine and amazing so far. Also built this thing on a cnc running duet 3. Very exited to have this continuous rotation feature now.

https://youtu.be/IkqkLaip2n0

dc42

I presume you are running RRF in CNC mode, as you are talking about needing to change the maximum speed in order to achieve a short slow move.

It appears to me that the fundamental problem is that when you move from e.g. -90 to +90 degrees, and it is a milling move, the G1 command does not provide a mechanism to specify the direction of movement. I could add a parameter to specify that; but perhaps that has been done in some Gcode variant already.

dc42

I've done some research, and it appears to me that in CNC mode it's normal to let the coordinates go on growing. So when at position A355, instead of sending G1 A1 you would send G1 A357. Eventually the numbers get too big and a reset is needed, typically using G92. Some controllers reset automatically if you switch into relative movement mode using G91.

dc42

@arhi said in Firmware package 3.2beta1 released:

@dc42 I know I'm being PITA but I have to and I apologize

It is impossible to figure out what are the branches of each project required to make a certain build. The BuildInstructions.md is not very up2date. So it would be cool if you could, for e.g. in these forum release posts, add info on what branch of each project goes into this release :). Ideally adding a same TAG as release on each product would be awesome

BuildInstructions.md was updated a week ago. https://github.com/Duet3D/RepRapFirmware/blob/v3.02-dev/BuildInstructions.md

All the projects that make up RRF 3.2beta1 are now tagged, except for DuetWiFiSocketServer.

arhi

@dc42 awesome!!! I missed the buildinstruction update, was looking at the wrong branch .. but tags are awesome thanks

dc42

Yes, it's a problem that project-wide files such as WhatsNew.md and BuildInstructions.md exist on so many different branches, it makes it hard to find the latest one.

jay_s_uk

@dc42 could the be moved to their own branch? Or maybe to a wiki for the repo so they aren't branch dependant?

dc42

@jay_s_uk said in Firmware package 3.2beta1 released:

@dc42 could the be moved to their own branch? Or maybe to a wiki for the repo so they aren't branch dependant?

Yes, moving them to a wiki would be a good solution I think.

arhi

@dc42 Yes, WIKI, either on github or duet3d.dozuki would be awesome ... dunno how many ppl build their own firmware but ..