Homing trouble after flashing dc42 firmware

I have just flashed my Ormerod2 to dc42's firmware RepRapFirmware-065k-dc42.bin, updated the web files, read the blog post Five Tips for using dc42 Firmware on the RepRapPro Ormerod.

It starts up fine and the web gui connects just fine. I can manually move the the printer head.
Homing the The Y-axis works fine via the serial monitor and the web gui.

I have no reading in the web ui of the proximity sensor. Using the Arduino serial monitor I can issue M31 and get a reading.

The X axis is where I get into trouble, via the web GUI it moves like 20mm towards the end stop (proximity sensor reading "shelve") and just stops. Trying again it moves 20 mm and stops.

Issuing G28 X0 via the serial monitor gave me the Windows system sound for USB device disconnect three times and after that no more response from the Ormerod, had to restart it.

Issuing M111 S2 n the serial monitor did not get me anything, at all. Doing it wrong?

I want to get a god foothold and have things behave before setting up the new homing approach with M208. Reading the blog post about changing to this firmware I came to the conclusion that modification of the G-file in the sys folder is optional, is this correct?

Where did I go wrong?
Please help.

Config.g file attached.

Hi fotomas, yes changing the config.g and homing files when switching to my fork is optional (but changing the web interface files is not). So I suggest you use the RRP homing and config files for the same firmware series initially.

Version 0.65k is very old now. Which version of RRP's firmware were you using before? If you were using RRP 0.78c, then I suggest you try my latest version 0.78y. There are incompatible changes between 0.65 and 0.78 series firmware that require wiring changes.

Edited 1 time(s). Last edit at 12/11/2014 06:39PM 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].

I did not realise that was an old version. Your blog pointed me here, stating that the newest relese would be listed there. [github.com]

I looked around and the 65k was the newest one. I probably got hold of a much newer Web interface too.

I came from the latest reprap version, submited in september.

So before doing any more trouble shooting I have to get the versions in sync and preferably the latest versions. As you suggest.

So the question is where can those be found? (Firmware/web)

Edited 1 time(s). Last edit at 12/12/2014 01:26AM by fotomas.

After poking aroung in GitHub I found the option to select diffrent branches. So I have found Version 0.78y

I am new to GitHub and come from Redmine and Team Foundation Server so there are a few things to get familiar with.

No running on firmware 78y and web gui 1.03.

Works without any trouble. Much more features, and what fast upload speed of G-Code files! The max travel speed of the motors is also much faster, dispite I have the same config.g file.

Thank you for the help in the post above but foremost making the firmware and web gui.

I have read the result of the bed compensation G32 is stored in the flash memory of the duet board, does this happen automatically and is reused every time? I only have to re-run G32 if I suspect that it has to be recalibrated?

I tested the print speed regulator, I could not notice that it had any effect. How is it supposed to work?

Hi fotomas, I'm glad it's working well for you now. I'm sorry you were directed to the wrong firmware initially. I have just updated the links in that blog entry to point to the newer branch.

The results of G32 are not currently stored in flash memory. So if you are using bed compensation, you should do a G32 at least once each time you power on or reset the printer. I could change the firmware store the results in flash memory if you think it would be useful.

Regarding the speed slider on the web interface, the firmware maintains a queue of around 30 moves, and the moves in that queue have already been calculated. So when you change the speed or extrusion factor, the results will not take effect for up to about 30 moves. If you 'print' circle.g while adjusting the slider, you should see the effect, because circle.g has lots of short moves. OTOH when you are doing rectilinear infill on a large print, the individual moves are very long, so it typically takes a long time for the slider to take effect. I have some work in progress that will eventually allow changes to the slider to take effect more quickly.

---

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

Regarding print speed: I see, as in so many cases; patience...
Does the speed regulating affect the travel speed too?

I think storing the G32 result would be useful. But the need for its is lesser now when the whole calibration process takes half the time and it its possible to do consecutive without restarting the printer (!). I have done my best calibrating the bed but never could get it quite right. Which can be seen on the bottom of bigger parts, (when not using the bed calibration). I have later read that if the Y-axis steel rods are not 100% parallel one gets an effect that seems like the bed is warped. But in fact bed tilts as its moves.

Anyway the bed calibration is the easy remedy for this so I use it all the time.

Quote
fotomas
... I have later read that if the Y-axis steel rods are not 100% parallel one gets an effect that seems like the bed is warped. But in fact bed tilts as its moves..

Yes and that's an easy fix:

[forums.reprap.org]

Erik

Quote
fotomas
I tested the print speed regulator, I could not notice that it had any effect. How is it supposed to work?

It turns out you were right, there is a bug in the speed adjustment in 0.78y. I will shortly release 0.78za-dc42 in which this is fixed.

---

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