RepRapFirmware 3.0RC1 released

A Former User

@dc42 said in RepRapFirmware 3.0RC1 released:

it doesn't separate bug reports from feature requests.

this can actually be configured, you can mark the issues with flags such as "bug", "feature request", "regression" etc etc .. also you can setup what needs to be filled in for bug to be consider "fully reported" and the github bot will autoreply that blah blah is missing and you ignore reports that are marked such way..

look for e.g. octoprint https://github.com/foosel/OctoPrint/issues

when you go to create new issue you get to:

there's a bunch of stuff you can setup on github to make your life easier and to allow for community to better help you ... I'm not a github (I use self hosted gitlab myself and for my company) expert but I'm sure we can get one if we ask to help set all this up

gtj0

@dc42 said in RepRapFirmware 3.0RC1 released:

@Phaedrux said in RepRapFirmware 3.0RC1 released:

The issue with this is that the average user is not really savvy enough to determine what is a bug and what is a configuration issue and typically just assume something must be a bug.

Exactly. My most common response to issues logged on the RRF repository in Github is along the lines of "This is a support question, use the forum". For a while I even disabled the Issues feature because I was getting so many support questions raised there.

Another weakness of github Issues is that it doesn't separate bug reports from feature requests.

Currently I track bug reports on a spreadsheet shared with my colleagues, linked back to the forum threads in which they were raised.

See. You want them here but @chrishamm wants them on github.
So if you want them here, which category and how would a user know?

T3P3Tony

Generally it appears that most things are dumped into general discussion (not just potential bugs but most things) with only a subset of people using the other categories. Where important and appropriate and I try to move them.

If we had a "bug report" category I am not sure that would make it more likely that bugs get reported there and other issues in the appropriate category. More likely there would still be bugs in general discussion and configuration issues in the "bug report" category.

OTOH think github is an appropriate place for developers to collaborate and point out bugs/issues (as you do!)

gtj0

No to beat a dead horse but did you know that as an open source project, you can get free licenses from Atlassian for Jira?

T3P3Tony

@gtj0 said in RepRapFirmware 3.0RC1 released:

Jira

very weary to try more tools at this point!

gtj0

@T3P3Tony said in RepRapFirmware 3.0RC1 released:

@gtj0 said in RepRapFirmware 3.0RC1 released:

Jira

very weary to try more tools at this point!

I know, I was more just pulling your leg.

Synapsis

@Phaedrux Thanks will stay with 2.05 for now.

fma

@Danal said in RepRapFirmware 3.0RC1 released:

My humble apologies for saying "We will always agree to disagree...". It was not you @fma; in fact you never posted to that thread.

I didn't take it for me, don't worry

There are perspectives in the user community that the overhead of merging a "bugfix only" N.0.N into N.1.0 would yield a negative return when implemented by a very small (almost one man) development team. We'd prefer to stick to the current arrangement.

I understand that RRF is not developped by a large company/community. But I developped a few free softwares myself, and didn't have much troubles to use major.minor.bf. But I admit I was not as active as David is (it was only on my free time): RRF is releasing tons of new great features very quickly... Maybe it could be acceptable to release less often?

I also know that it is much more interesting for a developper to add new features rather than fix bugs or refactor code. But these steps are mandatory for quality.

I always take Gimp as example: releases are very rare, but always great quality, and I never had a single crash with this software, nor nasty bugs. The team ensures the code is rock solid, and I think it is a very good approach, very respectfull for users.

Last, I apologize for putting coins in the juke box, and restarting that thread

Danal

@fma said in RepRapFirmware 3.0RC1 released:

Last, I apologize for putting coins in the juke box, and restarting that thread

Hey, no problem. Philosophical debates are kinda fun.

3dmntbighker

What does the new "standard" entry look like on a Maestro for a Duet3D PT100 daughter board?

M308 S1 Y"rtdmax31865" P"ctemp" F60 ; Activate PT100 hotend temp sensor

This gives me 2000C at ambient, and the pin names for the daughter board were not obvious to me.

 edit: Ah, so spi.cs1 (from Duet WiFi section) seems to be the secret sauce. How do you do the virtual driver listed below?

 ; M308 P101 X1001 S"DuetDriversTemp"	; Virtual heater to display stepper driver over temp flags

Also, without changing my numbers when I converted the old M305 to 308 for bed thermistor...

M308 S0 P"bed_temp" Y"thermistor" R4700 T100000 B3950

I got 6.4C at ambient. Before they were within a couple of degrees at ambient.

3dmntbighker

Next question...

After I set M669 K1 and run the CoreXY tests the motors run as expected. But running a simple "G91", "G1 H2 X10" results in both axis moving in plus direction. And "G1 H2 Y10" moves X+ and Y-.

gtj0

@3dmntbighker said in RepRapFirmware 3.0RC1 released:

Next question...

After I set M669 K1 and run the CoreXY tests the motors run as expected. But running a simple "G91", "G1 H2 X10" results in both axis moving in plus direction. And "G1 H2 Y10" moves X+ and Y-.

Do you mean "both axis moving" or "both motors moving"?

dc42

@3dmntbighker said in RepRapFirmware 3.0RC1 released:

Next question...

After I set M669 K1 and run the CoreXY tests the motors run as expected. But running a simple "G91", "G1 H2 X10" results in both axis moving in plus direction. And "G1 H2 Y10" moves X+ and Y-.

It's always been that way on CoreXY machines, because G1 H2 moves are individual motor moves.

3dmntbighker

@dc42 said in RepRapFirmware 3.0RC1 released:

@3dmntbighker said in RepRapFirmware 3.0RC1 released:

Next question...

After I set M669 K1 and run the CoreXY tests the motors run as expected. But running a simple "G91", "G1 H2 X10" results in both axis moving in plus direction. And "G1 H2 Y10" moves X+ and Y-.

It's always been that way on CoreXY machines, because G1 H2 moves are individual motor moves.

Well my homex no longer functions after changing S commands to H commands.

M400 ; make sure everything has stopped before we make changes
M913 X70 Y70 ; reduce motor current to 60% to prevent belt slipping
G91 ; relative positioning
G1 Z5 H2 F2000 ; drop bed relative to current position ; happens
G4 P250 ; wait 250msec
G1 X-300 H1 F3000 ; move quickly to X end stop and stop there (first pass) ; never happens
G4 P250 ; wait 250msec
G1 X30 F1000 ; Move Away 5mm X axis ; never happens
G1 X-35 H1 F2000 ; doesn't happen
M913 X100 Y100 ; motor current back to normal
G1 Z-5 H2 F200 ; drop bed relative to current position ; doesn't happen
G90 ; absolute positioning
G1 X20 F1000
M300 S600 P100

If I run Home X a second time nothing happens and I get a spinner.

deckingman

@3dmntbighker That's odd. Homing works for me on my CoreXY using H1. Mine is a bit complicated because it's actually a CoreXYUVAB but the pure X moves are essentially the same as yours. The major difference I see in your file is the use of G4 which I don't bother with. Try taking those out. If that fixes it, you may have found a bug.

Edit, There is one other difference in my homing files. I don't use H2 in the Z move - I have M564 H0 in my config.g to allow moves prior to homing. So if taking out the G4 commands doesn't fix it, try using M564 H0 instead of the H2 Z move and report back (in case you've unearthed a bug).

3dmntbighker

@deckingman said in RepRapFirmware 3.0RC1 released:

@3dmntbighker That's odd. Homing works for me on my CoreXY using H1. Mine is a bit complicated because it's actually a CoreXYUVAB but the pure X moves are essentially the same as yours. The major difference I see in your file is the use of G4 which I don't bother with. Try taking those out. If that fixes it, you may have found a bug.

Edit, There is one other difference in my homing files. I don't use H2 in the Z move - I have M564 H0 in my config.g to allow moves prior to homing. So if taking out the G4 commands doesn't fix it, try using M564 H0 instead of the H2 Z move and report back (in case you've unearthed a bug).

Now X doesn't move at all after the Z move...

M400 ; make sure everything has stopped before we make changes
M913 X70 Y70 ; reduce motor current to 60% to prevent belt slipping
G91 ; relative positioning
G1 Z5 F2000 ; drop bed relative to current position
G1 X-300 H1 F3000 ; move quickly to X end stop and stop there (first pass)
G1 X30 F1000 ; Move Away 5mm X axis
G1 X-35 H1 F2000
M913 X100 Y100 ; motor current back to normal
G1 Z-5 F200 ; drop bed relative to current position
G90 ; absolute positioning
G1 X20 F1000
M300 S600 P100

config.g

M111 S0 ; Debug off

; Network
M550 P"5Rails" ; Set machine name
M552 P192.168.1.100 S1 ; Enable network set IP
M553 P255.255.255.0 ; Netmask
M554 P192.168.1.1 ; Gateway
M586 P0 S1 ; Enable HTTP
M586 P1 S0 ; Disable FTP
M586 P2 S0 ; Disable Telnet

M555 P2 ; Set output to look like Marlin

; *** Machine configuration
M569 P0 S1 ; Drive 0 goes forwards (change to S0 to reverse it)
M569 P1 S1 ; Drive 1 goes forwards
M569 P2 S0 ; Drive 2 goes backwards
M569 P3 S1 ; Drive 3 goes forwards
M569 P4 S1 ; Drive 4 goes forwards

; Endstops
M574 X1 S0 P"xstop" ; X min active low endstop switch
M574 Y1 S0 P"ystop" ; Y min active low endstop switch
M574 Z1 S0 P"zstop" ; Z min active low endstop switch
M591 D0 P2 C"e0_stop" S1 ; E0 filament sensor active high

M669 K1 ; set CoreXY mode
M564 H0 ; Allow moves prior to homing
M92 X100 Y100 Z1000 ; Set axis steps/mm
M92 E415 ; Set extruder steps/mm
M350 X16 Y16 Z16 E16 I1 ; Configure microstepping with interpolation
M906 X1000 Y1000 Z800 E800 I50 ; Set motor currents (mA)
M201 X1000 Y1000 Z100 E900 ; Accelerations (mm/s^2)
M203 X40000 Y30000 Z800 E1800 ; Maximum speeds (mm/sec)
M566 X800 Y800 Z50 E800 ; Maximum jerk speeds mm/sec

M208 X300 Y275 Z330 ; set axis maxima (adjust to suit your machine)
M208 X0 Y0 Z0 S1 ; set axis minima (adjust to make X=0 and Y=0 the edges of the bed)
G21 ; Work in millimetres
G90 ; Send absolute coordinates...
M83 ; ...but relative extruder moves

; Z probe type
M558 P8 I1 R2 A5 F400 T3000 H5 ; Peizo Z probe, also used for homing the Z axis

G31 Z0.2 P600 ; Set the probe height and threshold (put your own values here)
M557 X25:275 Y15:265 S50 ;
M375 ; Load heightmap.csv
M376 H10 ; Taper off bed compensation up to 10mm

M308 S0 P"bed_temp" Y"thermistor" R2200 T100000 B3950 ; Put your own H and/or L values here to set the bed thermistor ADC correction
M308 S1 Y"rtd-max31865" R400 P"spi.cs1" F60 ; Activate PT100 hotend temp sensor
M950 H0 C"bed_heat" T0 ; heater 0 uses the bed_heat pin, sensor 0
M950 H1 C"e0_heat" T1 ; heater 1 uses the e0_heat pin and sensor 1
M501 ; Load config_override.g for 40W Auto tune
; M301 H2 P10 I0.10 D100 T0.50 S1.0 ; PID settings for extruder 1

; Tool definition
M563 P0 D0 H1 ; Define tool 0
G10 P0 S0 R0 ; Set tool 0 operating and standby temperatures

; *** If you are using axis compensation, put the figures in the following command
M556 S78 X0 Y0 Z0 ; Axis compensation here

T0 ; select first hot end

droftarts

@3dmntbighker Sounds like a similar issue to https://forum.duet3d.com/topic/13409/large-core-homing-issue

Ian

3dmntbighker

It doesn't matter if I set X end stop active high or active low. The axis won't home (move) unless I hold the switch on, and stops when I release.

deckingman

@3dmntbighker said in RepRapFirmware 3.0RC1 released:

It doesn't matter if I set X end stop active high or active low. The axis won't home (move) unless I hold the switch on, and stops when I release.

To clarify that, are you saying that you can change between S0 and S1 but the axis won't move unless you press the switch? What does M119 give you with and without the switch depressed?

3dmntbighker

@deckingman said in RepRapFirmware 3.0RC1 released:

@3dmntbighker said in RepRapFirmware 3.0RC1 released:

It doesn't matter if I set X end stop active high or active low. The axis won't home (move) unless I hold the switch on, and stops when I release.

To clarify that, are you saying that you can change between S0 and S1 but the axis won't move unless you press the switch? What does M119 give you with and without the switch depressed?

Correct

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

Pressed:

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

Also, after I attempt to home X nothing will move. None of the axis respond to the move buttons in the interface. Changing M574 from S0 to S1 gives the same result.