RepRapFirmware 3.0

gnydick

@dc42 as you know, I've pointed a number of issues around implicit logic vs explicit logic and my desire for there to be no implementation of implicit logic because it is not possible for an opinionated system to fit everyone's needs without requiring extra work by anyone who doesn't use the majority case.

I've been thinking about this after reading some of posts on this thread that demonstrate the coming complexity and others that propose implicit logic. That seemed like a bad idea, at first...

I have the beginnings of a concept, but not a concrete example yet. Maybe I can do a sufficient job in conveying my concept.

Some observation: I know the board is a CNC board. It is controlled by g-code. The current complex behavior co-opts g-code for the purpose of configuration.

Some opinion: I believe not all configuration should be in g-code. Assigning pins, for example. These are lower level than other configs because they change how the board presents itself to the things connected to it as well as what connection contract it's expecting.

I was thinking that since there is added complexity, a tiered configuration may make more sense.

My idea is to have personalities.

5-axis CNC
3-axis CNC
CoreXY printer
H-bot printer
Etc.

I think this separation cleans up the organization and presentation of configuration. It also allows for MORE implicit logic.

It'd be awesome to go to https://configurator.reprapfirmware.org/ and have a choice to pick from these personalities to begin the process and you input the high level configuration that seems appropriate for g-code like dimensions, tools, etc. All of those configs actually depend on the lower level config.

This would allow for a more concise g-code that isn't polluted with things that machine itself doesn't care about once it's personality is set.

dc42

@alexander-mundy said in RepRapFirmware 3.0:

Nevermind, I went back through this thread and found that I needed to explicitly release all 3 pins before remapping.

M950 H0 C"nil"
M950 H2 C"nil"
M950 F0 C"nil"
M950 H0 C"e1heat" Q10
M950 F0 C"bedheat" Q25500

Now when I plug the bed thermistor into the standard bed heat jack it reports in the web interface and bed heat appears to work.

I'm glad you got it working. A slight simplification should be possible, because assigning a pin to a device releases the existing pin used by that device. So the following should also work:

M950 H2 C"nil"
M950 H0 C"e1heat" Q10
M950 F0 C"bedheat" Q25500

The first command is needed to make pin "e1heat" available to use in the second command. The second command free up the "bedheat" pin, making to available in the third command.

dc42

@gnydick said in RepRapFirmware 3.0:

Some observation: I know the board is a CNC board. It is controlled by g-code. The current complex behavior co-opts g-code for the purpose of configuration.

Some opinion: I believe not all configuration should be in g-code. Assigning pins, for example. These are lower level than other configs because they change how the board presents itself to the things connected to it as well as what connection contract it's expecting.

There are two separate issues here: whether CNC mode/FDM mode should be controlled by GCode, and whether pin assignments should be controlled by GCode.

For CNC vs FDM mode, the choice was easy, because the M450 thru M453 commands has already been defined, documented, and implemented by Repetier firmware.

For pin configuration, I did consider using an alternative syntax, possibly related directly to the (not yet complete) object model. But it turned out that only one additional GCode command was needed (M950), and it was simpler to add it than to write a separate parser to handle a new syntax for configuring pin functions. Also, during development it is a huge advantage that I can reallocate pin functions on the fly, without needing to reboot the Duet each time I make a change.

I have considered whether some GCode commands such as M950 and M669 should be restricted to being recognised in config.g only. Or we could introduce a new GCode that disables recognition of M950, M669 and other potentially dangerous commands, and have configtool add that command to the end of config,g by default..

I was thinking that since there is added complexity, a tiered configuration may make more sense.

My idea is to have personalities.

5-axis CNC

3-axis CNC

CoreXY printer

H-bot printer
Etc.

I think this separation cleans up the organization and presentation of configuration. It also allows for MORE implicit logic.

It'd be awesome to go to https://configurator.reprapfirmware.org/ and have a choice to pick from these personalities to begin the process and you input the high level configuration that seems appropriate for g-code like dimensions, tools, etc. All of those configs actually depend on the lower level config.

There is certainly a lot more that could be done in configtool. But however much we do, there will be some configurations that it doesn't cater for. I think most users who build more advanced machines such as CoreXY and CNC machines are also the sorts of users who maintain their config.g and homing files by hand. However, it wouldn't be hard to create a number of generic machine profiles that can be imported to provide useful starting points.

gtj0

@dc42 said in RepRapFirmware 3.0:

However, it wouldn't be hard to create a number of generic machine profiles that can be imported to provide useful starting points.

Sounds like an opportunity for community participation.
Maybe a page on the wiki with machine descriptions and associated config.g?
Or maybe a moderated forum section where folks could post theirs?

gnydick

@dc42 I think there may be a little disconnect.

I wasn't suggesting CNC mode vs FDM mode, those just happen to be examples of types of machines, there could be laser engraver, etc. Technically, they are all CNC.

Also, my examples, like pins, were not meant to be an exhaustive list, are there no other config options that are low level?

A Former User

@gtj0 said in RepRapFirmware 3.0:

Maybe a page on the wiki with machine descriptions and associated config.g?

"Templates" for use with the online firmware configurator is already possible by means of the config.json file that can be loaded and changed as needed (as long as the configurator support making the neccecary changes or they can fit in the custom g-codes section at the end).

dc42

I have put a new RepRapFirmware 3 binary for Duet 2 at https://www.dropbox.com/s/fyvibzm0zl92hiy/Duet2CombinedFirmware.bin?dl=0. This restores support for M577, M581 and M582. See https://duet3d.dozuki.com/Wiki/RepRapFirmware_3_overview for details of changes to those commands.

The only RRF 2 feature not yet supported in RRF 3 is now the ability to use stall detection to terminate an extruder move.

smoki3

Today I switched to the 3.0.

@dc42 So I got everything to work besides the Z-Probe.

I use a normal mircoswitch connected to zstop pin on the duet2wifi.

But it tells me that it it always triggered.

I used this according to the documentation:

M574 Z0 C"nil" 				       ; no Z endstop switch, free up Z endstop input
M558 P5 C"zstop" H3 F180 T25000 I1 	       ; Z probe connected to Z endstop input

I also tried to remove the inversion "I1" and put an "!zstop" in the C command. But it doesnt help.

In DWC I see the probe value changes from 0 to 1000 if I press the switch. But the background of the value is always read

I played alot now with all the parameters. Looks like the probe is always trigged no matter which pin is selected. But I can not test an older build because the files in dropbox is replaced.

Here are some console outputs:

M119
Endstops - X: not stopped, Y: not stopped, Z: not stopped, Z probe: at min stop

M574
Endstop configuration: X: low end motor stall (any motor), Y: low end motor stall (any motor), Z: none

M558
Z Probe 0: type 5, input pin zstop, output pin nil, invert yes, dive height 3.0mm, probe speed 180mm/min, travel speed 25000mm/min, recovery time 0.00 sec, heaters normal, max taps 1, max diff 0.03

dc42

@smoki3 said in RepRapFirmware 3.0:

I use a normal mircoswitch connected to zstop pin on the duet2wifi.
But it tells me that it it always triggered.

What does - the M119 report, or something else? Are you saying that DWC shows the correct Z probe status, but M119 does not?

smoki3

for the outputs see my post above.

M119 shows always " Z probe: at min stop "

In the status windows i can see that the Z-probe value switches between 0 and 1000. But its always in read color

dc42

I found the problem. The threshold is not being initialised. A workaround is to put command G31 P500 (or whatever threshold you want to use) after the M558 command.

smoki3

@dc42 said in RepRapFirmware 3.0:

G31 P500

Thanks this works fine

jay_s_uk

@dc42 I've also upgraded to RRF 3.0 to try it out.
Previously, in RRF 2, when setting up a Z Probe, I used to have M558 H4. This H4 was added to the z probe offset so it would look for the bed, in my case, 31.66mm above z, as my probe offset is 27.66.
Now I'm having to use H30 as RRF 3 seems to be ignoring the z probe offset. Is this correct?

dc42

@jay_s_uk said in RepRapFirmware 3.0:

@dc42 I've also upgraded to RRF 3.0 to try it out.
Previously, in RRF 2, when setting up a Z Probe, I used to have M558 H4. This H4 was added to the z probe offset so it would look for the bed, in my case, 31.66mm above z, as my probe offset is 27.66.
Now I'm having to use H30 as RRF 3 seems to be ignoring the z probe offset. Is this correct?

No, that's not correct. RRF 3 should not ignore the Z probe offset, and I am fairly sure it doesn't on my printers.

The default M558 H value is 5. It's normally only necessary to increase it when aut-calibrating a delta printer for the first time, when the homed height and delta radius enters in the M665 command are likely to be inaccurate.

How come your Z probe trigger height (which is what I presume you mean by "offset") is as high as 31mm?

jay_s_uk

@dc42
I have a linear plus with an E3D hot end. So I use the probe that came with is as well as little block to allow me to miss the heat block on the hot end. This has increased the z probe offset somewhat from 16.8ish that comes as standard to 27.6ish.
Its works fine with RRF 2 without issue.
But switching over to RRF 3, the z probe was coming into contact with the bed way before it was actually triggering.
I increased the H from 4 to 30 and this allowed me to run G32 and the M500. But I've had to leave H as 30 otherwise the z probe comes into contact with the bed. And the gap it maintains between the probe and the bed is only around 3mm, hence why I think it is ignoring the z probe offset.

dc42

You are right, it's not adding the trigger height to the dive height. I will fix this in the next build. Thanks for reporting it.

jay_s_uk

At least I'm not going mad. Thanks

dc42

@jay_s_uk, please try the new binary at https://www.dropbox.com/s/zfv4p7dr2ycmjzd/Duet2CombinedFirmware.bin?dl=0.

jay_s_uk

@dc42 thats spot on

dc42

@jay_s_uk said in RepRapFirmware 3.0:

@dc42 thats spot on

Thanks for confirming!