That one is a doozie. It looked particularly long from my phone.
Unfortunately, there is no information in that which points to anything I have touched in Holey Calibration. The only helpful information is you changed the PWM frequency to be empty. It looks like there may be something going on, since the PWM frequency is a calculated setting.
I didn’t make the PWM frequency empty intentionally, it crashed when I tried to
set the PWM frequency (with what generally looks like a similar error)
I tried renaming groundcontrol.ini and letting it generate a new one, just in
case there was something bad in it. I got the same error when I tried to open a
file with the newly generated groundcontrol.ini file.
David Lang
Now I think I am understanding what is going on. I have looked at PWM frequency as a parameter in the *.ini file. Being a calculated parameter, it has a different format than the others. Its format is something like ‘490Hz’, which translates to the number 3 in the Firmware. When I implemented the modified version of the Firmware Sync, I didn’t account for this translation. Actually, there was already a translation, but this wasn’t included in it.
Having said that, as long as there is no Sync issue with the calculated parameters, it should work.
I haven’t tried it, but for now, it might work to just set the PWM frequency to 3, which is interpreted as 490Hz in the Firmware.
unfortunantly this machine is 35 miles away, so it will be a couple days before
I get there to test this.
David Lang
I am still struggling to make progress on this one. What I have found, that is interesting, is that my (kivy/uix/behaviors/togglebutton.py) file is different than yours. Line 107 for yours shows “if self.active:”. When I look at mine, it is different. my line 107 is “group.remove(item)”. Here is a screen print:
I did a search (CTRL+F) for the text “active”, and I found nothing in the whole togglebutton.py file, or in the tabbedpanel.py file. This leads me to the question of why they are different. Is there any possibility that kivy is either outdated or modified on your machine?
Also, I haven’t yet looked into handling the empty/default case.
It’s more likely that my kivy is newer, next time I’m out there I’ll post a link
to the instructions I used to install kivy
David Lang
how hard would it be for you to produce the GroundControl.exe binary like the stock version does? I attempted to get things working with a windows tablet and gave up quickly due to all the other stuff I needed to install before I could try to run it.
here are the instructions I followed to get kivy installed. I didn’t do the
config stuff to setup the touchscreen after it was installed.
I added
import kivy
print "Kivy Version: ", kivy.version
and got:
Kivy Version: 1.11.0.dev0
David Lang
I just pulled kivy again and did a new install
$git log
commit 0f39c0d04ebc5455a55c7e160e4ab86413a189bc (HEAD -> master, origin/master,
origin/HEAD)
Author: matham moiein2000@gmail.com
I just had the stock GC fail the same way, so it’s something on my system
what version of kivy are you running?
David Lang
I apologise for not following this close enough to know the answer, but quick question, does holey calibration add any new settings to ground control and firmware that gets synced?
Yeah. It does. However, most of those changes were committed by @c0depr1sm, and those commits are already in the main Fork.
I see I’m behind the curve on stock maslow support… I’ll work to at first get the settings incorporated to handle groundcontrol.ini imports as a start.
Is this for WebControl, or GroundControl?
he is orking to update WebControl to catch up with the capabilities in the
firmware and the holey triangular GroundControl.
David Lang
There’s a difficulty with incorporating holey calibration into webcontrol as it is. Currently, webcontrol supports the use of custom firmware, but just one version. I don’t want to break my ability to use my custom optical calibration firmware, so we need to figure out how to handle two (or more) custom firmwares. Webcontrol determines if a firmware is custom or not by looking at the version number. If it’s over 100, then it’s custom (my optical calibration firmware just adds 100 to the stock firmware version number… e.g., 101.25). Holey calibration would be viewed as stock firmware because it’s version is less than 100. The simple way would be to change the version number of holey calibration to 200+version and then I can test on that. It would then make incorporating the special settings into webcontrol easier.
My thought is more like we should resolve the conflicts between the two versions of the firmware, so that they become one. We wouldn’t have to maintain two versions moving forward.
From what I understand, the primary conflict is the correction matrix in web control, and the implementation of chain stretch and sag correction in Holey. There may be conflicts with the parameter identifiers which would need to be addressed.
I understand and appreciate the sentiment, but let’s just try to get them to work side-by-side for the time being… too many fires in the iron. I’ll modify optical calibration to move the specific firmware keys up in the 90’s or something…
However, webcontrol can work with different firmware and send only specific “custom” firmware keys when it knows the firmware is custom and therefore needs some way to be told that the firmware is custom. As I mentioned, for optical calibration firmware, I upped the version # by 100. For holey calibration firmware, can the version number be increased by 200… so the current 1.26 becomes 201.26? This will also facilitate enabling the holey calibration routine in webcontrol since, if the version isn’t 200<=x<300, the holey calibration routine button will be disabled. That way someone running stock firmware won’t try to calibrate using the wrong routine.
I am a little nervous about this. The Holey Calibration process uses GC kinematics.py to do the kinematics calculations. In order for this to result in an accurate calibration, this has to align exactly with the kinematics calculations in the Firmware. So, if someone uses Holey Calibration to calibrate the wrong Firmware, the result will be an inaccurate machine, and the problem will be assigned to the calibration.
Not sure I follow. Webcontrol won’t allow someone to calibrate using holey calibration unless their firmware is a holey calibration firmware… assuming webcontrol knows its a holey calibration firmware, that’s why I suggested the +200 fix to the version number. That’s how it works with optical calibration… if the controller doesn’t report a firmware >100 (i.e., its a stock firmware), then the optical calibration button is disabled.