RepRapFirmware 3.0

dc42

Was the extruder motor connected directly to an output on the Duet?

oliof

Yes, to output "E0" on the duet wifi board.

4lathe

Sane for me. Just loaded latest 3.0 and modified my m558 as I use fsr’s on endstop e0. Motion control all fine as is bed and nozzle heat bur the extruder E0 will not extrude or retract. Its at temperature.

carlosspr

Same here using RepRapFirmware 3.0beta3 (2019-05-16b1) . In my case I have two tools (two extruders and one heater). The following is the configuration of my TOOLS section:

;_____ TOOLS
M563 P0 D0 H1                       ; Define tool 0 to use extruder drive 0 and heater 1
G10 P0 S0 R0 X0 Y0                  ; set tool 0 temperatures and offsets
M572 D0 S0.1			    ; Pressure advance enable for extruder 0

M563 P1 D1 H1                       ; Define tool 1 to use extruder drive 1 and heater 1
G10 P1 S0 R0 X0 Y0                  ; set tool 1 temperatures and offsets
M572 D1 S0.1			    ; Pressure advance enable for extruder 1

None of the tools would move, neither with temp nor forcing cold extrusion with M302

dc42

Run M584 and check whether the extruders are mapped to drivers 3 and 4.

carlosspr

@dc42 Yes they are mapped to drivers 3 and 4. The result of M584 is : Driver Assignments X0 Y1 Z2 E3:4, 3 axes visible.

dc42

Thanks, I will look into it.

Sytac072

Hello, I have a single extruder configuration. I just tried to install the RepRap firmware 3 and I had had the same problem, no way to move the extruder motor.

dc42

I will do a new RRF3 beta release next week. I need to do another 2.03RC release first.

dc42

I am planning a new build of RRF 3 later this week, incorporating the recent improvements in RRF 2.03RC3. Meanwhile, I think you can probably get extrusion working if you use M584 to assign extruder drives explicitly. Although M584 appears to shows the correct extruder drive mapping by default, in reality the extruder data has not been set up fully.

MoczikGabor

@veti said in RepRapFirmware 3.0:

@dc42 said in RepRapFirmware 3.0:

The current plan is 30V or perhaps 36V. It's difficult to find 5V buck regulator chips that accept higher than 40V input.

why not says that for input above 30V the 5V line has to be supplied via the ext 5V?

I think that the board could have separate V_MOT and V_IN terminals.
The V_MOT could accept higher voltage which would go solely to the motor drivers.
The V_IN could accept 25-30V max as you will probably need 12/24V for the hotends or fans anyway, or for other automation purposes in CNC. This is how I usually do in custom machines I design.

Those who don't need higher voltage or anything special just have to connect the V_MOT and V_IN parallel, those who need it could use two power supplies.

Alexander Mundy

@dc42 Sorry for my confusion but if you (or anyone) could help me I would appreciate it. I just got the delta endstops and homing working but I do have 2 things remapped. My bed heat SSR's are connected to E1 and my part fan is connected to H0.

I managed to get the part fan working with:
M950 F0 C"bedheat" Q25500

Autotuned the hotend but the bed is the problem.
For the bed I am trying:

M140 H2 (without this the thermistor shows 2000 in web)
M950 H0 C"e1heat" Q10

And when I try autotune I get:
M303 H0 S110
Error: heater 0 reported error 'unknown temperature sensor channel' at start of auto tuning

The web interface shows the bed temp
alt text

What am I doing wrong?

Alexander Mundy

A little further testing.

M950 H2 C"nil"
M950 H0 C"e1heat" Q10

Sending "M950 H0"
I receive "Heater 0 pin e1heat, frequency 10Hz"

However the bed temp in the web interface shows 2000 with the thermistor plugged into either the board bed heat or E1 spots.

Alexander Mundy

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.

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