New firmware 1.00-dc42

Ok.
But i have 1.00a firmware.

Quote
Mercnik
Ok.
But i have 1.00a firmware.

Sure, but you also tried 1.00b, and the next release (1.00c) will be developed from that.

---

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

I've just tested the RRP modulated IR sensor with version 1.00b, and it is working correctly. I get readings like 16 (23) when the sensor is not near anything, and 487 (502) when it is approaching a white surface. I'm in a south-facing room, the weather is cloudy, and the room has LED lighting. The difference between the bracketed and unbracketed readings is a measure of the background IR, which in my case is caused by sunlight.

If you work in a room with little or no sunlight, and the artificial light is LED or fluorescent, then you will have very little background IR and the two readings will be the same. To test it, turn on an incandescent light. Or shine a torch/flashlight with an old-fashioned bulb (not LED) at the sensor. Either should give you a difference between the two readings.

---

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

I tried with 1.00 and 1.01, same issue. I tried the same gcode file 3 times, it stopped at different print durations, well in the print (don't have the exact time, but like after 5min 20min and 3rd time after 45min). I didn't touch the Panel at all after starting the print. But still if I unplug the Panel everything is fine.
I don't have time to test right now, but will answer your other question later.
Is there any additional logfile I could create to help debug that issue? I'm wondering if either the Panel or the Duet goes through an (watchdog) reset. Could this cause such kind of an issue?

Quote
dc42
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.

If I read pantau's posts correctly, he has sometimes had the hotend switch off mid-print. If so it sounds as if the PanelDue has had a touchpanel input deselecting the head, maybe an accidental touch, an erroneous touchpanel output (due to vibration?) or electrical noise on the touchpanel signal lines. There is also an outside possibility that the touchpanel driver has a bug that gives ghost outputs under some conditions (typically when interrupts occur or are disabled at a critical time). I am not familiar with your panel interface, but if it is possible to switch to a screen where there are no buttons present that would deselect the tool, pantau could try switching to that screen after the print is underway.

Given the possibility of accidentally touching the screen (depending where it is mounted), maybe consider a way of minimising the risk of an accidental touch ruining a print that is underway, such as "lock" and "unlock" functions.

I once lost several hours work when a cat I was looking after for a friend jumped onto my keyboard and managed to hit just the right key combination. My fault for not saving the work often enough, but I was not pleased with the cat!

Dave

Quote
dmould

Quote
dc42
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.

If I read pantau's posts correctly, he has sometimes had the hotend switch off mid-print. If so it sounds as if the PanelDue has had a touchpanel input deselecting the head, maybe an accidental touch, an erroneous touchpanel output (due to vibration?) or electrical noise on the touchpanel signal lines. There is also an outside possibility that the touchpanel driver has a bug that gives ghost outputs under some conditions (typically when interrupts occur or are disabled at a critical time). I am not familiar with your panel interface, but if it is possible to switch to a screen where there are no buttons present that would deselect the tool, pantau could try switching to that screen after the print is underway.

Given the possibility of accidentally touching the screen (depending where it is mounted), maybe consider a way of minimising the risk of an accidental touch ruining a print that is underway, such as "lock" and "unlock" functions.

I once lost several hours work when a cat I was looking after for a friend jumped onto my keyboard and managed to hit just the right key combination. My fault for not saving the work often enough, but I was not pleased with the cat!

Dave

Good input, was thinking about similar things as well:

Electric noise: I got the assembly from Think3dprint3d. They supply a fairly long unshielded, untwisted wiring harness, which runs right across my (noisy) ATX power supply. Will try with harness rerouted. Thinking about it could really be the issue. I was successfully printing the day before, just after receiving the panel. Then I "cleaned up" my harness and integrated the panel...
Lock input : Maybe the settings page already is like this, will check.
Cat: That one I can rule out :-)

Thanks

Peter

ok, i thought the b version is only for delta. and a is for others, and that you will be developing two different firmwares. my mistake.

If you carefully remove the shield from a thick coax cable that has a braided construction (e.g. RG-59), this can be slipped over a bunch of wires and pulled tight - the plaited wire tube will contract or expand as it is stretched or pushed shorter. Then cover with heatshrink. Connect only the Duet end of the shield to ground.

Dave

The Files page of the user interface doesn't have the Head 1 and Head 2 buttons. Maybe next release I'll disable turning heads off and moving the heads while a print is in progress, unless the print is paused first.

If the print stops again, you can check whether the printer has reset due to a watchdog by sending M122. Also, if the printer has reset, then the axes will show as not homed.

A little over a year ago in the first few days of printing with my Ormerod 1, I used to get occasional firmware hangs during printing. The weather here was very stormy at that time and power brownouts were fairly common. I added an extra capacitor to my Duet board and made a few other changes to it, and the problem went away.

---

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

Strangely IR Z probe works fine now. It computes modulated value.
I'm not shure why? not that i'm complaining
And i did not do any configuration to my config. or any other file.

I've just released version 1.00d of my firmware fork. Changes in this release:

Quote

* Added M575 command to set baud rate and whether or not commands are required to have checksums. See [reprap.org].
* Default aux baud rate is now 57600.
* Added support for a Z probe switch connected to the E0 endstop pins.
* Added "geometry" variable in M105 S3 status response.

The compatible web interface is still 1.04. If you use a PanelDue, then you will need to either upgrade the PanelDuet firmware to 1.02, or use a M575 P1 B115200 command in config.g to increase the baud rate.

---

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

just got my Ormerod 2 and am going to try 1.00e, but you quote web interface 1.04, where can i download that from

sorry found it now, ignore me.....

Edited 1 time(s). Last edit at 02/04/2015 05:46AM by wmacm00.

Hey DC.

i know this is probably going to seem like an obvious question.. but what is the best way to update the firmware?

i have not done it for ages so was thinking i would try the RRP website way. but i cant for the life of me find the bossac.exe im guessing the newest arduino versions dont still have it? sould i just pull the SD card and overwrite the files?

Quote
nistrum
Hey DC.

i know this is probably going to seem like an obvious question.. but what is the best way to update the firmware?

i have not done it for ages so was thinking i would try the RRP website way. but i cant for the life of me find the bossac.exe im guessing the newest arduino versions dont still have it? sould i just pull the SD card and overwrite the files?

The firmware is not stored on the SD card, you will need Bossac - I've attached it to this post (along with "listcomports" which could be useful to find which port you are plugged into).

I have also attached "reprog.cmd" which is the easy way to reprogram. First find what COM port your erased Duet comes up on (which will usually be different to the port it comes up for Pronterface when it has Ormerod firmware loaded). You can run "listcomports" from a command (DOS) window to find out. Now open the file "reprog.cmd" in a text editor (you can right click and select "edit" or "open with notepad" etc. Change the COM port to whichever one your unprogrammed Duet comes up on, save and exit the editor.

Now all you have to do to reprogram the Duet is to drag & drop the firmware file onto the "reprog.cmd" icon or listing and follow the prompts.

Dave

awesome. thanks. not sure what they have done with the bossac file...

all sorted now, thanks.

i felt brave and decided i would try the good old Z probe to do the automated bed leveling.. still useless. it gives me diferent results each time but none of them are ever the actual bed height..

If the Z probe gives you different results each time, I guess you are using the Ormerod 1 unmodulated Z probe, and you have sunlight or incandescent artificial light interfering with the reading.

---

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

yeah. other than building it an enclosure i have no hope, its in my office. would the newer modulated IR probe help?

The new modulated IR probe us a lot better than the original Ormerod 1 probe. In my tests, it was 15 times less sensitive to ambient IR than the original.

My differential IR sensor (https://miscsolutions.wordpress.com/ormerod-hot-end-board-v2/) is even better and works anywhere on the bed; but I sold the last one yesterday. I will make some more if I get enough orders.

---

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

hahah. i was on your page looking at trying to find out how to order one. i didnt know how much they were or how much pain i was going to cause trying to install it or i would have emailed you

Took the plunge today and went straight from last official RRP 0.78 release to dc42's 1.00g. I've been meaning to do this for quite some time now as I have been getting increasingly fed up with the bugs in the RRP 0.78. To be fair - the actual printing worked ok - but it was the general sparse functionality and unreliability of the web interface interface which I wanted to improve on.

As hoped for - the upgrade was easy to do and my Ormerod 2 was back up and running in a few minutes. Initially I didn't realise that the link was just to the actual firmware and that I needed the whole package to get the web 1.04 files. Otherwise I just made the recommended mods to the config and homing files.

For some reason on the web interface did die on the first print - but seemed okay after that. I also noticed the the hot end took a lot longer to come up to temp (I'm sure thats been discussed before). I also noticed the bed leveling happened slightly closer to the far x of the bed - but that was easily fixed by adding a bit more white PVC tape under where the sensor was positioned.

The printer certainly has a different feel and after the first layer or so seems to absolutely rip through the print at high speed. Something I wasn't expecting - but the printer seemed to hold up well. I did bump the hotend and bed temp up 5 deg as the 1st print after the upgrade did come unstuck and the web interface suggested that the hotend wasn't quite up to the desired temp - which was set a bit on the low side anyway.

Generally though - I'm very pleased and would like to thank dc42 (and any other contributors) for all the hard work which has gone into this.

:-)

mrrgstuff

---

mrrgstuff

(3d printing/Ormerod 2 videos on YouTube - search: mrrgstuff)

Little issue, after homing all axes, y0 is about 10mm out of bed (-10), I'have made some upgrade recently, so I'am not sure when this issue is started, but it seems so strange....
I'm thinking to add a line like

M208 Y -10 S1

But I'm not so sure that it is correct

this is my config.g

; Configuration file for RepRap Ormerod
; RepRapPro Ltd
M111 S0                             ; Debug off
M550 PRaffyBuffy			        ; Machine name (can be anything you like)
M551 Preprap                        ; Machine password (currently not used)
M540 P0xBE:0xEF:0xDE:0xAD:0xFE:0xED ; MAC Address
;*** Adjust the IP address and gateway in the following 2 lines to suit your network
M552 P192.168.1.14                  ; IP address
M554 P192.168.1.1                   ; Gateway
M553 P255.255.255.0                 ; Netmask
M555 P2                             ; Set output to look like Marlin
G21                                 ; Work in millimetres
G90                                 ; Send absolute coordinates...
M83                                 ; ...but relative extruder moves
M906 X800 Y1000 Z800 E1000           ; Set motor currents (mA)
M563 P1 D0 H1                       ; Define tool 1
G10 P1 S0 R0                        ; Set tool 1 operating and standby temperatures
M92 Z2133							; Set Z steps per mm
M92 E420                        	; Set extruder steps per mm (single nozzle)
;*** If you have a dual-nozzle build, remove ot comment out the previous line, and un-comment the following 3 lines
;M563 P2 D1 H2                      ; Define tool 2
;G10 P2 S0 R0                       ; Set tool 2 operating and standby temperatures
;M92 E420:420						; Set extruder steps/mm (dual nozzle)
;*** If you have a modulated IR probe without on-board microcontroller, change P1 to P2 in the following
M558 P1                             ; Use an unmodulated Z probe or an intelligent Z probe
G31 Z0.3 P500                       ; Set the probe height and threshold (put your own values here)
;*** If you have a Duet 0.7 board, change R1000 to R4700 to the following M305 commands
M305 P0 R1000 H0 L0					; Put your own H and/or L values here to set the bed thermistor ADC correction
M305 P1 R1000 H26 L0					; Put your own H and/or L values here to set the first nozzle thermistor ADC correction
M305 P2 R1000 H0 L0					; Put your own H and/or L values here to set the second nozzle thermistor ADC correction
;*** Adjust the XY coordinates in the following M557 commands to suit your build and the position of the IR sensor
M557 P0 X60 Y60                     ; Four... 
M557 P1 X60 Y165                    ; ...probe points...
M557 P2 X165 Y165                   ; ...for bed...
M557 P3 X165 Y60                     ; ...levelling
M557 P4 X141 Y82.5                 ; 5th probe point for levelling (un-comment this if you are using a dc42 differential IR probe)
;*** if you are using axis compensation, put the figures in the following command
M556 S78 X0 Y0 Z0                   ; Axis compensation here
M201 X800 Y800 Z15 E1000            ; Accelerations (mm/s^2)
M203 X15000 Y15000 Z100 E3600       ; Maximum speeds (mm/min)
M566 X600 Y600 Z30 E20              ; Minimum speeds mm/minute
M208 X214 Y210						; set axis maxima (adjust to suit your machine)
M208 X-8 S1							; set axis minimum (adjust to make X=0 the edge of the bed)
M574 X0 Y2 Z0 S1					; set endstop configuration (Y endstop only, at high end, active high)

Is it an Ormerod 1 or 2, and are you using my homing files or RRP's? You can use either, but on the O1 mine behave a little differently from RRP's:

- RRP's homing files includes a G92 command after the homing move, because homing won't work without it using their firmware.

- Mine don't have the G28 command. Instead, the firmware sets the Y position to the value given in the M208 command (which you have set to 210) when it senses the high stop. On my machine, the nozzle is right at one end of the bed when the endstop is triggered, so Y=210 this is about right. But if you have your Z axis mounted in a different position on the Y extrusion so that the nozzle can't quite reach the left hand end of the bed, then you may need to reduce that 210 figure.

---

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

File for David (easier to attach it here), have sent PM about it.

Quote
dc42
Is it an Ormerod 1 or 2, and are you using my homing files or RRP's? You can use either, but on the O1 mine behave a little differently from RRP's:

- RRP's homing files includes a G92 command after the homing move, because homing won't work without it using their firmware.

- Mine don't have the G28 command. Instead, the firmware sets the Y position to the value given in the M208 command (which you have set to 210) when it senses the high stop. On my machine, the nozzle is right at one end of the bed when the endstop is triggered, so Y=210 this is about right. But if you have your Z axis mounted in a different position on the Y extrusion so that the nozzle can't quite reach the left hand end of the bed, then you may need to reduce that 210 figure.

Thank you Dc42,
Mine is a O1 with your homing files, the problem was for the value 210 for M208 now I set it to 200 and It's ok!
Many Thanks

So I Installed 1.00h today to replace the stock firmware. Great improvement. Runs a lot smoother and the extended functionality of the web interface is great.

I have found that when I run G32 to auto compensate the Bed it uses the positions in the Bed.g file instead of the M557 positions in Config.g. Is this Correct?

Thanks for your work updating this firmware!

Thanks! G32 runs the bed.g file if it exists, otherwise it uses the probe points set by M557.

---

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

Great. Figured it was that simple.

Files for DC42

Dave