Firmware package 3.2beta1 released

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 ..

jay_s_uk

@arhi I tried to build it once.... Gave up

arhi

@jay_s_uk said in Firmware package 3.2beta1 released:

@arhi I tried to build it once.... Gave up

I built it few times so far, setting up env on mac is super easy .. on windows I gave up as it was interfering with my other stuff .. but I had issues with getting proper versions of all sub-projects... anyhow once you get over that it's rather easy ... much more important part is actually understanding the code and making use of ability to compile it

observatoer

This post is deleted!

A Former User

This is what i get for a Maestro Board 3.1.1 running -> 3.2beta1 DuetMaestroFirmware.bin

Veti

@Nellor

this is a topic about 3.2

please read the documentaiton. you need to update to 3.0 first.