Issue Calibrating - "Pull chain tight and measure" doesn't stop pulling

I never meant to imply this is due to anything related to the EEPROM updates. I don’t think that is related.

When mentioned this way, it looks like this may very well be a mistake on my part. Below is a piece of code I modified in the Holey Calibration fork, to limit the number of lines printed to the log.txt file. Woops.

HoleyCalModsToLogFile

Lines 149 through 152 are intended to only record once every 1 second, the logical value populated to recordLine. If the Measurement response starts with “[”, it would likely be filtered out because of the logic on line 149.

Seems like there needs to be slightly more sophisticated logic on 149, which only filters out the machine positions, and lets the [Measurement: xxx] messages through.

I’d like to think through all the messages the Firmware will transmit, so that we can think of robust logic that won’t continue to give us problems here. Further, I am not sure why this message is enclosed in brackets, whereas most others are not.

What is the strategy which defines which messages are enclosed in brackets, and which are not?

2 Likes

I didn’t take it that way… all good.

As for the logging work, that could explain it.

@Joshua Is it possible to use the filter to gate write events to the logfile rather than dropping machine responses? I would have to think that additional code will spring up that traps and acts on info returned by the controller, or does the log also function as the serial in buffer?

1 Like

good find either way!

I think those kind of changes should be in logger.py. that’s where webcontrol does it.

@JohnC, if you are able to test it, can you modify your serialportthread.c file to change line 156 from

if recordline:

to

if True:

@madgrizzle yep, no worries. I’ve got a 10YO showing me all the cool new things she discovered in Minecraft so might take a bit. :crazy_face:

3 Likes

You got the priorities right.

2 Likes

“B10” sent via macro returns nothing to the console area of GC. Same result after changing the line in serialportthread.py. I tried to check the log.txt but I can’t find one.

My path to Main.py is “C:\Users\me\Documents\GroundControl-master”. Any idea why the log file isn’t being created?

1 Like

I think the log file is created in c:\users\me (iirc)

You could do a search for log.txt just to make sure it isn’t hiding somewhere.

groundcontrol.ini is here

Log.txt should be here

Not sure why it wouldn’t be there. Here is a screenshot of mine:
image

The only instance of “log.txt” is in the folder I keep the official distro in. Last mod date is 8/4 so not it.

Correct.

yep, I’m a little stumped on this. I’ll nuke the folder and DL it again tonight.

2 Likes

Any chance you actually ran a different install of it? I used to have 3 to 4 different versions of ground control on my PC.

Nah, I’ve got two instances but I know the folders. plus the log.txt that I did find has too early a last mod date. It’ll be easy enough to just DL it again.

1 Like

isn’t the file groundcontrol.log not log.txt?

It should be the same place as groundcontrol.ini

David Lang

I did a search of my entire PC for “groundcontrol.log” and it didn’t find anything.
I’ve only ever seen log.txt, which is in the “groundcontrol-master” folder, where “main.py” is.

1 Like

look for files where groundcontrol.ini is

David Lang

I think it is named “log.txt”

1 Like

I went ahead and commented this change to schmittjoshc/GroundControl repository.

Till date not seen that. From win$10 i know the .ini in C:/users/{your-user-name} and the log.txt in the same folder as the main.py. Linux ~/home/{your-user-name} for the .ini and GC folder for the log.

2 Likes

Let me begin by admitting that I’m an idiot…

I launch GC with a shortcut that calls python.exe to run main.py. On closer inspection of said shortcut the “Start In” folder was wrong.

I have located a precariously placed log.txt in “C:\python27” and the “if True:” fix works.

Some days a guy just can’t win. :man_facepalming: SNARF

3 Likes