New firmware 1.00-dc42
Posted by dc42
|
New firmware 1.00-dc42 January 24, 2015 09:36AM |
Registered: 10 years ago Posts: 14,672 |
I'm pleased to announce the release of this latest version of my firmware fork at [github.com]. As I had run out of letters to append to 0.78, and the RRP dev branch is already up to version 1.02, I have taken the liberty of calling this version 1.00. This is the firmware series that I am recommending for use with PanelDue.
The main changes in this release compared to my last few 0.78 series releases are:
For a full list of changes comparef to RRP 0.78c, see [github.com].
The web interface currently supported is 1.04 as before. I am liaising with zombiepantslol, and I expect to support his new web interface in this firmware series in the future.
If you are upgrading from my 0.78 series firmware or from RRP 0.78c, please note the following:
1. If you choose to keep your existing config.g file, you should add a line to configure the endstops. For Ormerod 1 use this:
For Ormerod 2 use this:
2 If you choose to keep your existing homing files, you will find that the final X homing is done very slowly. This is because the original RRP homing files specify 200mm/min as the fine X-homing speed, but that was well below the minimum enforced by the firmware. You can fix this by increasing the speed from 200 to (say) 500 in the G4 X command.
3 If you are running RRP 0.78c then you will need to update the /www files and subfolders on the SD card.
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
The main changes in this release compared to my last few 0.78 series releases are:
Quote
- The move code has been almost completely rewritten. It no longer uses the Bresenham algorithm to calculate step times, which in general led to non-uniform intervals between step pulses except when moving along the X or Y axis. Instead, the step intervals are calculated to the nearest microsecond using Newton's laws of motion.
- The minimum feed rate is now 0.5mm/sec for all axes. The M566 command is still used to set the maximum instantaneous speed change for each axis.
- Extruder elasticity compensation is supported (M572 command) In truth, I have not yet achieved the improvement in print quality that I was expecting from this feature. One of the problems is that if I set it to more than about 0.1, then the additional retraction tends to cause the filament to get stuck in the Bowden tube where it joins the hot end. But it is there to try if you want to.
- Endstops can now be configured properly (M574 command).
- The firmware now supports delta printers. Switching into delta mode is done using the M665 command. See [miscsolutions.wordpress.com] for how I converted my Mini Kossel to use Duet electronics.
- Debugging can now be enabled and disabled separately for all modules (M111 command). The module is selected using the P parameter.
- Additional status code 'C' is returned if the printer is polled while it is processing config.g. This is mostly so that the PanelDue can determine when the machine name and other parameters are stable.
For a full list of changes comparef to RRP 0.78c, see [github.com].
The web interface currently supported is 1.04 as before. I am liaising with zombiepantslol, and I expect to support his new web interface in this firmware series in the future.
If you are upgrading from my 0.78 series firmware or from RRP 0.78c, please note the following:
1. If you choose to keep your existing config.g file, you should add a line to configure the endstops. For Ormerod 1 use this:
M574 X0 Y2 Z0 S1 ; set endstop configuration (Y endstop only, at high end, active high)
For Ormerod 2 use this:
M574 X0 Y1 Z0 S1 ; set endstop configuration (Y endstop only, at low end, active high)
2 If you choose to keep your existing homing files, you will find that the final X homing is done very slowly. This is because the original RRP homing files specify 200mm/min as the fine X-homing speed, but that was well below the minimum enforced by the firmware. You can fix this by increasing the speed from 200 to (say) 500 in the G4 X command.
3 If you are running RRP 0.78c then you will need to update the /www files and subfolders on the SD card.
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
|
Re: New firmware 1.00-dc42 January 24, 2015 10:33AM |
Registered: 9 years ago Posts: 395 |
|
Re: New firmware 1.00-dc42 January 24, 2015 12:52PM |
Registered: 9 years ago Posts: 191 |
Updated and ran into some trouble.
Ormerod 2 fw 1.00 (obviously)
Homing works but when running the bed calibration (G32) it doesn't seem to use the coordinates in the config.g
when it is suposed to use M557 P0 X28 Y15 it goes to X0 Y15.
Which puts the sensor outside the bed.
What have I missed?
/Tomas "fotomas"
Ormerod 2 fw 1.00 (obviously)
Homing works but when running the bed calibration (G32) it doesn't seem to use the coordinates in the config.g
when it is suposed to use M557 P0 X28 Y15 it goes to X0 Y15.
Which puts the sensor outside the bed.
What have I missed?
/Tomas "fotomas"
Quote
config.g
M111 S0 ; Debug off
M550 fotomas Ormerod 2 ; Machine name (can be anything you like)
M551 Preprap ; Machine password (currently not used)
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED ; MAC Address
M552 P192.168.0.65 ; IP address
M553 P255.255.255.0 ; Netmask
M554 P192.168.0.1 ; Gateway
M555 P2 ; Set output to look like Marlin
G21 ; Work in millimetres
G90 ; Send absolute corrdinates...
M83 ; ...but relative extruder moves
M906 X1000 Y1000 Z800 E1000 ; Set motor currents (mA)
;M305 P0 R4700 ; Set the heated bed thermistor series resistor to 4K7
;M305 P1 R4700 ; Set the hot end thermistor series resistor to 4K7
M569 P0 S0 ; Reverse the X motor
M92 E425 ; Set extruder steps per mm
M558 P1 ; Use a differential LED Z probe
M574 X0 Y1 Z0 S1
G31 P500 Z2.58 ; Set the probe height and threshold
M557 P0 X28 Y15 ; Bed calibration coordinates
M557 P1 X28 Y194
M557 P2 X196 Y194
M557 P3 X196 Y15
;M556 S78 X-1.0625 Y-0.875 Z0.25 ; Put your axis compensation here
M201 X500 Y500 Z15 E500 ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z200 E3600 ; Maximum speeds (mm/min)
M566 X500 Y500 Z30 E500 ; Minimum speeds mm/minute
M563 P1 D0 H1 ; Define tool 1
G10 P1 S20 R-273 ; Set tool 1 operating and standby temperatures
|
Re: New firmware 1.00-dc42 January 24, 2015 02:36PM |
Registered: 10 years ago Posts: 14,672 |
Hi Tomas, I'll see if I can reproduce that tomorrow.
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
|
Re: New firmware 1.00-dc42 January 24, 2015 05:04PM |
Registered: 9 years ago Posts: 395 |
|
Re: New firmware 1.00-dc42 January 24, 2015 05:06PM |
Registered: 9 years ago Posts: 191 |
Further findings:
To get past the problem above I reset the X position to 0 at X 15 to get the G32 to measure at a resonable position. Then when issuing a G32 it never left the X0 position. It measured several times at the X0 corners. After this the connection in the webGUI was lost.
A possibly related issue I have discovered is that in the 0.78za firmware communication is also lost after about 8-12 consecutive G32 commands. I did a LOT of calibrations testing my modified Y-idler bracket (posted in another thread).
/Tomas
To get past the problem above I reset the X position to 0 at X 15 to get the G32 to measure at a resonable position. Then when issuing a G32 it never left the X0 position. It measured several times at the X0 corners. After this the connection in the webGUI was lost.
A possibly related issue I have discovered is that in the 0.78za firmware communication is also lost after about 8-12 consecutive G32 commands. I did a LOT of calibrations testing my modified Y-idler bracket (posted in another thread).
/Tomas
|
Re: New firmware 1.00-dc42 January 25, 2015 05:51AM |
Registered: 10 years ago Posts: 14,672 |
I'm looking into this now. The probe points set by M557 are getting corrupted. Until I have fixed this, either use a different version of the firmware, or don't use G32.
EDIT: I found the problem and will release a fix shortly.
Edited 1 time(s). Last edit at 01/25/2015 05:58AM by dc42.
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
EDIT: I found the problem and will release a fix shortly.
Edited 1 time(s). Last edit at 01/25/2015 05:58AM by dc42.
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
|
Re: New firmware 1.00-dc42 January 25, 2015 06:22AM |
Registered: 10 years ago Posts: 14,672 |
The issue with G32 is fixed in release 1.00a-dc42, which I have just released.
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
|
Re: New firmware 1.00-dc42 January 25, 2015 06:42AM |
Registered: 9 years ago Posts: 191 |
|
Re: New firmware 1.00-dc42 January 25, 2015 04:02PM |
Registered: 9 years ago Posts: 102 |
I have just installed the new firmware 1.0a-dc42 coming from 78 something. The "engine" sound is completly different! Doesn't sound so rough anymore.
Haven't done any printing yet as i am also upgrading my hotent venting but thats something for a different thread...
The first print is much slower with unchanged slic3r settings than with the older firmware? Pushing the speed slider to 200% of the webinterface
seems to give the same speed as with the old firmware. Any ideas why that is?
Edited 1 time(s). Last edit at 01/25/2015 06:12PM by tstone.
Haven't done any printing yet as i am also upgrading my hotent venting but thats something for a different thread...
The first print is much slower with unchanged slic3r settings than with the older firmware? Pushing the speed slider to 200% of the webinterface
seems to give the same speed as with the old firmware. Any ideas why that is?
Edited 1 time(s). Last edit at 01/25/2015 06:12PM by tstone.
|
Re: New firmware 1.00-dc42 January 26, 2015 02:48PM |
Registered: 9 years ago Posts: 73 |
I haven't done any firmware updates for a while.
and now i have updated frpm 0.78r to 1.00b
So i just want to know, if I have an modulated Z probe, on Ormerod 1,
and I have:: M558 P2 ; Use an modulated Z probe :: command
do I have to make any changes to Homex, homey, homez, or homeall files??
It seems that Z probe is shoving identical values for compensated and uncompensated reading.
Edited 1 time(s). Last edit at 01/26/2015 03:59PM by Mercnik.
and now i have updated frpm 0.78r to 1.00b
So i just want to know, if I have an modulated Z probe, on Ormerod 1,
and I have:: M558 P2 ; Use an modulated Z probe :: command
do I have to make any changes to Homex, homey, homez, or homeall files??
It seems that Z probe is shoving identical values for compensated and uncompensated reading.
Edited 1 time(s). Last edit at 01/26/2015 03:59PM by Mercnik.
|
Re: New firmware 1.00-dc42 January 26, 2015 03:41PM |
Registered: 10 years ago Posts: 14,672 |
No, upgrading from 0.78t to 1.00a does not require any changes to start gcode, just the change to config.g that I described at the top of this thread.
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
|
Re: New firmware 1.00-dc42 January 26, 2015 03:49PM |
Registered: 10 years ago Posts: 14,672 |
Quote
tstone
The first print is much slower with unchanged slic3r settings than with the older firmware? Pushing the speed slider to 200% of the webinterface
seems to give the same speed as with the old firmware. Any ideas why that is?
That probably means you selected quite a slow print speed in slic3r, and some of the generated gcodes were below the minimum speed supported by the old firmware. I noticed a long time ago that this always tended to happen with first layer perimeter speeds In my prints. The infil speed should be unaffected, unless you have that set at alow speed too.
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
|
Re: New firmware 1.00-dc42 January 26, 2015 04:14PM |
Registered: 9 years ago Posts: 73 |
I flashed the updates. Things seem to be working fine.
I just have a problem with Z probe.
So i just want to know, if I have an modulated Z probe, on Ormerod 1,
and I have:: M558 P2 ; Use an modulated Z probe :: command in config
do I have to make any changes to Homex, homey, homez, or homeall files??
It seems that Z probe is shoving identical values for compensated and uncompensated reading
In old original RRp files there was an Command line ';M558 P2' in homeall I think, and I just uncommented it (deleted the ; )
And the probe was working fine.
I just have a problem with Z probe.
So i just want to know, if I have an modulated Z probe, on Ormerod 1,
and I have:: M558 P2 ; Use an modulated Z probe :: command in config
do I have to make any changes to Homex, homey, homez, or homeall files??
It seems that Z probe is shoving identical values for compensated and uncompensated reading
In old original RRp files there was an Command line ';M558 P2' in homeall I think, and I just uncommented it (deleted the ; )
And the probe was working fine.
|
Re: New firmware 1.00-dc42 January 26, 2015 04:51PM |
Registered: 10 years ago Posts: 14,672 |
You should be able to use the same homing files with 1.00a that you were using with RRP 0.78c.
RRP 0.78c uses quite a low modulation frequency, and RRP found that for X homing, it was better to switch it into unmodulated mode. So in homex.g and homeall.g for the Ormerod 2, they switch to unmodulated mode (M558 P1) before X homing, and back to modulated mode (M558 P2) afterwards. My fork uses a higher modulation frequency, and I think you should be ok to use modulated mode for X homing too.
In fairness, I haven't tested with a simple modulated probe for several versions, so it is possible that a fault has crept in to the firmware. Can you confirm that it is 1.00a that you flashed, or did you flash 1.00b?
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
RRP 0.78c uses quite a low modulation frequency, and RRP found that for X homing, it was better to switch it into unmodulated mode. So in homex.g and homeall.g for the Ormerod 2, they switch to unmodulated mode (M558 P1) before X homing, and back to modulated mode (M558 P2) afterwards. My fork uses a higher modulation frequency, and I think you should be ok to use modulated mode for X homing too.
In fairness, I haven't tested with a simple modulated probe for several versions, so it is possible that a fault has crept in to the firmware. Can you confirm that it is 1.00a that you flashed, or did you flash 1.00b?
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
|
Re: New firmware 1.00-dc42 January 26, 2015 05:05PM |
Registered: 9 years ago Posts: 73 |
|
Re: New firmware 1.00-dc42 January 26, 2015 05:55PM |
Registered: 10 years ago Posts: 14,672 |
Quote
Mercnik
I flashed 1.00b as posted
Try 1.00a. There have been changes to the z probe handling in 1.00b in order to support delta printers, but you don't need those changes for the Ormerod, and it's possible that they have broken the support for probe type 2.
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
|
Re: New firmware 1.00-dc42 January 27, 2015 12:42AM |
Registered: 9 years ago Posts: 73 |
|
Re: New firmware 1.00-dc42 January 27, 2015 12:50PM |
Registered: 9 years ago Posts: 73 |
|
Re: New firmware 1.00-dc42 January 27, 2015 03:54PM |
Registered: 10 years ago Posts: 14,672 |
Mercnik, when you said "It seems that Z probe is shoving identical values for compensated and uncompensated reading.", what exactly did you mean? Did you mean that with probe type 2 set (using M558 P2), you get a reading something like "413 (413)", or something else?
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
|
Re: New firmware 1.00-dc42 January 27, 2015 04:19PM |
Registered: 9 years ago Posts: 73 |
|
Re: New firmware 1.00-dc42 January 27, 2015 04:26PM |
Registered: 10 years ago Posts: 14,672 |
Does the reading increase as the head nears the white tapes on the bed, and go down to near-zero when the head is a long way from the bed?
If so, that sounds like a software bug to me, so please accept my apologies I will test 1.00b with a simple modulated IR sensor tomorrow.
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
If so, that sounds like a software bug to me, so please accept my apologies I will test 1.00b with a simple modulated IR sensor tomorrow.
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
|
Re: New firmware 1.00-dc42 January 27, 2015 05:03PM |
Registered: 9 years ago Posts: 73 |
Well, i think, that the reading is ok. the numbers go up when head is close and go down, when is far away. I made two sucessful prints. But as i've said both numbers are the same.
I had same problem, when i used original homing files. With M558 P2 commented out.
I think its just a bug
And as i have said i flashed 1.00A.
There is no problem, ofcourse bugs happen
You are doing great job, and I'm wery thankfoul for all your help.
I had same problem, when i used original homing files. With M558 P2 commented out.
I think its just a bug
And as i have said i flashed 1.00A.
There is no problem, ofcourse bugs happen
You are doing great job, and I'm wery thankfoul for all your help.
|
Re: New firmware 1.00-dc42 January 27, 2015 05:36PM |
Registered: 10 years ago Posts: 14,672 |
Do you have the IR sensor connected to the correct pins,as shown here: [reprappro.com] ? The pin numbers on the expansion connector that the Z probe connects to changed at version 0.78.
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
|
Error: Attempting to extrude with no tool selected January 27, 2015 05:53PM |
Registered: 9 years ago Posts: 38 |
My setup is Ormerod 1 with firmware 1.00b-dc42 and PanelDue 1.00
While trying to print a file I get this error:
23:11:03 Error: Attempting to extrude with no tool selected.
23:08:10 File [Frsky_d4r_V_mount.g] sent to print
21:03:48 T:B:33.4
21:03:47 M115
FIRMWARE_NAME:RepRapFirmware FIRMWARE_VERSION:1.00b-dc42 ELECTRONICS
uet (+ Extension) DATE:2015-01-25
I tried with different files, and the error happend always, but every time at a different time/location during the print. It also happend on a file which printed ok yesterday with no issues.
When the error happens both heaters are switched off, head is in standby and can't be reactivated, bed accepts new temperature setpoint and I can still move axes manually.
I don't think it's a slic3r error as the files worked yesterday.
The only change is that I uploaded one more file to the SD card. Didn't count, but what would happen if I exceed the char count limit?
After many tries I disconnected the PanelDue and that print went through!
Problem is that I had it connected yesterday as well and the prints were ok. Today I updated the Panel to 1.01 but just after the print failure. And it didn't fix the problem. So it doesn't seem to be the version.
The only other explanation I have is that today I used the Panel "Print" screen which I didn't do yesterday. But on the many tries I did I'm not completly sure that I was always in the print screen on the failure.
Could it be a lookup of the Duet due to the Panel data flow?
While trying to print a file I get this error:
23:11:03 Error: Attempting to extrude with no tool selected.
23:08:10 File [Frsky_d4r_V_mount.g] sent to print
21:03:48 T:B:33.4
21:03:47 M115
FIRMWARE_NAME:RepRapFirmware FIRMWARE_VERSION:1.00b-dc42 ELECTRONICS
uet (+ Extension) DATE:2015-01-25I tried with different files, and the error happend always, but every time at a different time/location during the print. It also happend on a file which printed ok yesterday with no issues.
When the error happens both heaters are switched off, head is in standby and can't be reactivated, bed accepts new temperature setpoint and I can still move axes manually.
I don't think it's a slic3r error as the files worked yesterday.
The only change is that I uploaded one more file to the SD card. Didn't count, but what would happen if I exceed the char count limit?
After many tries I disconnected the PanelDue and that print went through!
Problem is that I had it connected yesterday as well and the prints were ok. Today I updated the Panel to 1.01 but just after the print failure. And it didn't fix the problem. So it doesn't seem to be the version.
The only other explanation I have is that today I used the Panel "Print" screen which I didn't do yesterday. But on the many tries I did I'm not completly sure that I was always in the print screen on the failure.
Could it be a lookup of the Duet due to the Panel data flow?
|
Re: Error: Attempting to extrude with no tool selected January 27, 2015 06:18PM |
Registered: 10 years ago Posts: 14,672 |
Hi pantau, I don't think it has anything to do with the PanelDue. This message:
means that you still have tool 0 (the empty tool) selected. Here are some ways of fixing it:
* Put a T1 command in your start gcode in whatever slicing program you are using (this is the recommended solution).
or
* Before printing, if in the web interface Head 1 status is shown as "Standby", click on the "Head 1" text, which will change the status to Active
or
* Before printing, if on the Panel Due the Head 1 current temperature does not have a red background, this means that head 1 is not active. Touch the Head 1 text, and this should make the head active and change the current temperature background to red.
Note that a T1 command in config.g will fix the problem for the first print you do after a power up or reset, but not for subsequent prints, because when the first print completes, tool 0 is selected by the M0 or M1 command that is typically in the end gcode.
This behaviour is a consequence ot RRP making tool 0 the empty tool. In principle this is a good idea, however it has caught a few people out. Maybe in the next release of my firmware, if a "set hot end temperature" command is received when tool 0 is selected, I should select tool 1 automatically?
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Quote
Error: Attempting to extrude with no tool selected.
means that you still have tool 0 (the empty tool) selected. Here are some ways of fixing it:
* Put a T1 command in your start gcode in whatever slicing program you are using (this is the recommended solution).
or
* Before printing, if in the web interface Head 1 status is shown as "Standby", click on the "Head 1" text, which will change the status to Active
or
* Before printing, if on the Panel Due the Head 1 current temperature does not have a red background, this means that head 1 is not active. Touch the Head 1 text, and this should make the head active and change the current temperature background to red.
Note that a T1 command in config.g will fix the problem for the first print you do after a power up or reset, but not for subsequent prints, because when the first print completes, tool 0 is selected by the M0 or M1 command that is typically in the end gcode.
This behaviour is a consequence ot RRP making tool 0 the empty tool. In principle this is a good idea, however it has caught a few people out. Maybe in the next release of my firmware, if a "set hot end temperature" command is received when tool 0 is selected, I should select tool 1 automatically?
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
|
Re: Error: Attempting to extrude with no tool selected January 27, 2015 06:37PM |
Registered: 9 years ago Posts: 38 |
Dave, thanks for the quick reply. But prior to posting I did google for the error and did get the same explanation. I checked T1 occurance. I have it only in Goode and just once. No t0 anywhere.
Key is that I am successful with the same files and same config.g without panel connected, which failed when panel connected. To reproduce I switch the printer off for each trial and start all over. I had 5 tries failing with panel and just finished the second successful while disconnected. Same gcode files same printer config. Only difference is panel. Need more trails to see if it is a specific screen on the panel.... Not sure if it matters for all trials I also used the web interface in parallel.
Key is that I am successful with the same files and same config.g without panel connected, which failed when panel connected. To reproduce I switch the printer off for each trial and start all over. I had 5 tries failing with panel and just finished the second successful while disconnected. Same gcode files same printer config. Only difference is panel. Need more trails to see if it is a specific screen on the panel.... Not sure if it matters for all trials I also used the web interface in parallel.
|
Re: Error: Attempting to extrude with no tool selected January 27, 2015 07:02PM |
Registered: 10 years ago Posts: 14,672 |
Hmm - strange! I've just checked the PanelDue source code, and the only time it sends T0 is if you touch either the Head 0 or Head 1 text when that head is already active.
Can you use either the web interface or the PanelDue to check whether tool 1 is active when you start the print, and when it goes inactive? The web interface displays the head status in small text under the Head 1 or Head 2 text. PanelDue does it by setting the background colour of the active head current temperature to red.
Also, if you are still running version 1.00 PanelDue firmware, please upgrade to version 1.01 so that we are both using the same version. The firmware version number is displayed on the Setup page.
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Can you use either the web interface or the PanelDue to check whether tool 1 is active when you start the print, and when it goes inactive? The web interface displays the head status in small text under the Head 1 or Head 2 text. PanelDue does it by setting the background colour of the active head current temperature to red.
Also, if you are still running version 1.00 PanelDue firmware, please upgrade to version 1.01 so that we are both using the same version. The firmware version number is displayed on the Setup page.
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
|
Re: New firmware 1.00-dc42 January 28, 2015 12:35AM |
Registered: 9 years ago Posts: 73 |
|
Re: New firmware 1.00-dc42 January 28, 2015 04:16AM |
Registered: 10 years ago Posts: 14,672 |
Quote
Mercnik
Yes, it is connected the right way. it worked fine with your version 0.78r.
I'll test 1.00b with the RRP modulated IR sensor late today - I just need to make the cable up.
Edited 1 time(s). Last edit at 01/28/2015 04:18AM by dc42.
Large delta printer [miscsolutions.wordpress.com], E3D tool changer, Robotdigg SCARA printer, Crane Quad and Ormerod
Disclosure: I design Duet electronics and work on RepRapFirmware, [duet3d.com].
Sorry, only registered users may post in this forum.