Not saving correct bed offset

[ra100]

I just tried twice to manually calibrate offsets and this is what I got

.	1	2	3	4
BL orientation	0.737433	0.826397	0.92155	0.947852
BR orientation	0.269793	0.508255	0.347733	0.333615
FR orientation	-1.068147	-1.137964	-1.075883	-1.044552
FL orientation	-0.342318	-0.550029	-0.375969	-0.303444
BL offset	0.705867	0.363703	0.22835	-0.847952
BR offset	1.493341	0.911845	0.802167	-0.233715
FR offset	0.828347	0.798164	2.225783	1.144452
FL offset	0.601342	0.510229	1.525869	0.403344
BL+	1.4433	1.1901	1.1499	0.0999
BR+	1.763134	1.4201	1.1499	0.0999
FR+	-0.2398	-0.3398	1.1499	0.0999
FL+	0.259024	-0.0398	1.1499	0.0999

Calibrations 1 a 2 are older ones, 3 and 4 are from today. last values with + are orientation + offset, and it struck me weird that I've managed to have the same values there. In the 4th calibration in FR and FL I just tried to save values, then move head lower and save again, values stayed same.

serial.txt

[donovan6000]

Should be fixed now. I added line numbers to the commands that get sent by the buttons to guarantee that none of the commands are ignored. However the printer wont provide normal feedback to commands when they have line numbers, so I had to add cases for sending those kind of commands.

With line numbers send: N1 M114 recv: ok N1

Without line numbers send M114 recv: ok Z:43.32

So since M114 was never returning a Z value, M3D Fio was just using the same starting Z value for everything which caused all the orientation + offset to be the same. Can you also check if this fixed #58 too?

[ra100]

Values seem more believable now. And #58 is fixed.

[ra100]

But it seems I first need to reconnect printer to load new orientation values and then calibrate offsets to get better results. It seems like bed offset values are calculated from old bed orientation values.

[donovan6000]

Ok, it's really fixed now. I was forgetting to request the new settings after running the bed orientation calibration portion of the complete bed calibration so it was using the older settings for the corner offset calculations.

[ra100]

I am not sure it worked. Before calibration I set all offsets/orientations to 0m and after full calibration (when I opened settings) all orientation values were 0 and offset were "ok". I'll test it more later..

[donovan6000]

Just ran a test and got the same behavior where all the bed orientations were 0 after it was all done. I'll look into this more.

[donovan6000]

Fixed it. When sending commands in a group, most commands sent after sending the calibrate bed orientation command, G32, were ignored. So all the commands to get the new bed orientation values were never processed.

Thanks for helping me get the bed calibration perfect!

[ra100]

It worked fine this time. Although it is impossible for me to have nice test border after full calibration, but I've had this problem from the start. I'll need to improve my manual calibration skills :)

[donovan6000]

Can you also help me fix a problem that one of the guys over at M3D's forums is having? It kinda difficult to fix issues when working with someone who doesn't understand Python or OctoPrint enough to diagnose the problem, and it's Raspberry Pi related so I can't test it myself.

I just need you to enable the 'Use external fan' options and use any GPIO pin number. You don't need to connect anything to the pin, so the pin number you use arbitrary.

Then run the commands 'M106 T1' to set that pin high and 'M107' to set that pin low. According to what the guys saying, running one of these commands is causing the printer to disconnect. So I assume there's an issue with M3D Fio's external fan functions. So it'd be awesome if you could let me know if you experience the same disconnecting issue or if OctoPrint logs any useful errors related to the RPi.GPIO module when running those commands.

[ra100]

No problem, I tried it and this is what I got. Printer disconnected just after M106 T1 command. And it seems, problem is, that without root you can't use /dev/mem

serial.log

Recv: wait .......................................................
Recv: 
Send: M106 T1
Unexpected error while writing to serial port: RuntimeError: 'No access to /dev/mem.  Try running as root!' @ comm.py:_doSendWithoutChecksum:1849
Changing monitoring state from 'Operational' to 'Error: RuntimeError: 'No access to /dev/mem.  Try running as root!' @ comm.py:_doSendWithoutChecksum:1849'
Connection closed, closing down monitor
Closing down send loop

octoprint.log

2016-02-09 23:16:35,190 - octoprint.util.comm - ERROR - Unexpected error while reading from serial port
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/OctoPrint-1.3.0.dev861+gb51274c-py2.7.egg/octoprint/util/comm.py", line 1491, in _readline
    ret = self._serial.readline()
  File "build/bdist.linux-armv7l/egg/serial/serialposix.py", line 475, in read
    raise SerialException('device reports readiness to read but returned no data (device disconnected or multiple access on port?)')
SerialException: device reports readiness to read but returned no data (device disconnected or multiple access on port?)
2016-02-09 23:17:50,635 - octoprint.util.comm - ERROR - Unexpected error while writing to serial port
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/OctoPrint-1.3.0.dev861+gb51274c-py2.7.egg/octoprint/util/comm.py", line 1849, in _doSendWithoutChecksum
    self._serial.write(cmd + '\n')
  File "/usr/local/lib/python2.7/dist-packages/OctoPrint_M3DFio-0.25-py2.7.egg/octoprint_m3dfio/__init__.py", line 2712, in processWrite
    self.turnOnExternalFan()
  File "/usr/local/lib/python2.7/dist-packages/OctoPrint_M3DFio-0.25-py2.7.egg/octoprint_m3dfio/__init__.py", line 7056, in turnOnExternalFan
    RPi.GPIO.setup(fanPin, RPi.GPIO.OUT)
RuntimeError: No access to /dev/mem.  Try running as root!

[ra100]

From what I found, you need to use some other option to access gpio that doesn't use /dev/mem, because octoprint can't run as root and running it as sudo -u pi octoprint doesn't work either. I didn't put much time to this, but maybe this could help: http://abyz.co.uk/rpi/pigpio/python.html pigpio library for python.

[donovan6000]

Thanks. So I just read there's two ways to access the pins: from /dev/mem or from the file system. The later can be done in userspace, so it should work without root access.

So give the latest devel build another go since it now uses the file system access method.

[donovan6000]

According to this comment, Raspbian includes a udev rule that sets it so that members of the gpio group can access /sys/class/gpio. Since OctoPi is just a modified version of Raspbian, it should include that udev rule but I'm not sure if the pi user is in the gpio group.

Can you confirm that /sys/class/gpio is owned by the gpio group? ls -l /sys/class/gpio

And that the pi user is in that group? grep "^gpio" /etc/group

[ra100]

Well, I don't have standard raspbian installation, I've got xubuntu on my Rpi2 so I get this But I'll try to look at rules in raspbian and make it work. But it will take some time.

sh: 1: cannot create /sys/class/gpio/export: Permission denied
sh: 1: cannot create /sys/class/gpio/gpio24/direction: Directory nonexistent
sh: 1: cannot create /sys/class/gpio/gpio24/value: Directory nonexistent

[donovan6000]

The guy at the forum just confirmed that it's working on OctoPi, so you don't need to worry about getting it working. He's the person who requested the external fan feature, so it's pretty much just for him. Thanks for all the help again!

I did find out that you can run OctoPrint as root with sudo octoprint --iknowwhatimdoing, but running a web server with root access seems way too risky. I'm glad we found an alternative.

[ra100]

OK, glad to help. When I'll need gpio, I'll have to figure it out.