ah, perfect, thanks

Thanks @dc42

@dc42 I was trying to add project in vscode. It was taking too much time create Makefile so left it in half. Thank you for the help Sir.

@dc42 said in Pull Request: Fine grained heater control:

RRF 3.2 will provide a means for switching tools between active and standby. I'd like to consider the feature you propose in that context.

In particular, what is the use case for tool switching tool heaters individually between off and standby, rather than switching the entire tool between off and standby?

I don't have a use case for that. I was just being flexible in the design. Since you can have multiple heaters for a tool I thought being able to control them separately was the most future-proof. Although, there isn't a way to set different temps for them at this time maybe there should be, I'm not sure. Maybe for preheating some material or something along those lines?

And yes, external tools works fine. Its only internal tools that don't.

Brilliant, thank you.

We’ve not built this particular firmware before but we can certainly look at this.

Thanks again.

Cheers,

James

@dc42 nice, I recompiled it on mac, was faster to get everything up and running without messing out working envinronments for other stuff on my main win desktop and compiling is fast enough that the speed of the mac is not that important 😄 .. brew is a nice addon to osx 🙂 .. brew installs (GNU Tools for Arm Embedded Processors 9-2019-q4-major) 9.2.1 20191025 (release) [ARM/arm-9-branch revision 277599] so exactly what you say you are using for 3.1.1 and the issue is only with src/GCodes/GCodeBuffer/ExpressionParser.cpp the conv.Accumulate is called with wrong number of parameters .. probbly ReprapFirmware:v3-dev vs RRFLibraries:dev at point I was doing a clone were out of sync (I see that whole section is new) ... I just needed to do the quick read of the ADC so I removed that whole section and compiled without a problem 😄 .. got data I needed I returned release 3.1.1. 🙂 ..

I moved to 2020 myself for few projects and so far did not notice any issues

Yes, that's what happens when a response to an HTTP command is too big to fit in the available output buffers.

@dc42 "works well" doesn't mean it couldn't work better. I wasn't asking to change how the OM is created or stored or maintained, just to re-arrange the output to make it work better and it's a high-level change at that. Basically just moving the top-level objects down one level into "state", "meta" and "platform". I'm also not suggesting that it go into RRF 3.x, just "some future release".

@chrishamm No but specifying "/machine/model?key=boards" will return a full model on DSF and boards on RRF3. Or just maybe, DSF can support the "key" parameter.

With the addition of maybe 1 parameter (maybe "platform"?) we can then tell which 3.X platform we're connected to, RRF or DSF with just 1 call. This is easier than having to try different scenarios and falling back until we find one that works.

@dc42 I'm not looking to do anything to it. I was just confused by the "msgBox.seq" format but since that only happens when you don't specify a type, I'm fine. DueUI always specifies a type.

@gtj0, I can only think that you were running firmware 3.0 or another older firmware version.

@dc42 said in What's the best practice to test G-code during a debug session?:

@Sejl said in What's the best practice to test G-code during a debug session?:

@dc42 said in What's the best practice to test G-code during a debug session?:

You could try sending the command via the PanelDue serial port. Caution: it uses 3.3V signal levels; 5V will damage the MCU.

Duet 3 Hardware Overview web page says: "The inputs will tolerate up to 30V. The outputs are 3.3V signals levels with 470R series resistors."

I would like to know how can you damage MCU with 5V if input is tolerating up to 30V?

Best regards

I stand corrected. On Duet 3, PanelDue connects to the IO_0 connector, which is indeed tolerant of 30V on the input pin. On Duet 2 and Duet 085 it tolerates 3.3V maximum.

Thank you!

Thanks for quick reply!

So i understand there is no any protocol description and i can only rely on sources in this topic?

Moved to Firmware Developers forum.

Hmm, I don't think there is anything exactly like that in RRF. But to try and achieve your end goal of quieter fast travel moves maybe give M566 P1 a try.

https://duet3d.dozuki.com/Wiki/Gcode#Section_M566_Set_allowable_instantaneous_speed_change

The default jerk policy is 0, which replicates the behaviour of earlier versions of RRF (jerk is only applied between two printing moves, or between two travel moves, and only if they both involve XY movement or neither does). Changing the jerk policy to 1 allows jerk to be applied between any pair of moves.

I'll probably sort it out. Just venting a bit 🙂

@dc42 Not that I'm aware of... I've looked through the repetier repo and I can't find a document that covers the responses. I suspect that it would require going through the code.

@Danal said in RRF Version numbers and tagging:

To me, the bigger problem is lack of mapping from 'apt' releases to "V3.01 RC11" nomenclature.

Yeah, I don't use the packages because I compile and test a lot but it would make sense that the reprapfirmware package have the same version as the firmware it contained.