Topics created by gtj0

@T3P3Tony said in WiFiSocketServerRTOS mismatch between project name and repo name:

@gtj0 Thanks. I fixed those links

Thanks Tony!

@dc42 Ah, gotcha. I hadn't thought of doing it that way probably because all of my other Eclipse based projects (I've got about 25 of them) use the Eclipse builder to just run make or ninja, etc. on existing build scripts. Since 3.3 is EOL and you're planning to move 3.4 to gcc 12.2 anyway, it'snot really an issue any more. If it becomes one for 3.6 or later versions I can easily do the separate workspace thing as you do.

Thanks!

@dc42 Are you going to do this or should I submit a pull request for it?

@gtj0
If it's any consolation ... err ... what was I going to say?

@chrishamm Cool, thanks!

@chrishamm OK, no problem. In the mean time, I'll go through the latest DSF commits and checkout what's already there.

@chrishamm Cool, thanks!

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

@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 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?

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

@dc42 said in Will RRF and the support libs move to the Duet3D repo?:

All done.

THANKS!