offsetpage_widget.py error while running smartprob

Actually I got at least one detail of the interpreter's sequence of operations wrong. Please review Interp::save_parameters for the accurate sequence. However, it's still the case that at a certain step of the interpreter updating the contents of the var file, the var file is temporarily unavailable. And based on my current reading, there are additional moments where the file exists but its contents are not completely written (most likely, you would see an empty file but it is not impossible that you might see only the initial portion of the file)

Updating the file "in place" is not feasible for two reasons. First, because the numbers "1" and "10" take a varying number of bytes. Second, because the implementation of variable file writing needs to read the old variable file to determine which numbered parameters are saved.

I am not opposed to designing a better sequence for the interpreter to write out the variable file; perhaps a scheme which uses UNIX hard links can even ensure that the var file always exists and is always complete. But that kind of change is much harder to get right than having code which reads the var file deal gracefully with it not being present or not containing all the usual values. It is my opinion that a patch to fix the latter is a much better choice to bugfix a stable version of linuxcnc.

For the master branch I would be happy to review a patch to improve var file writing but unless it turns out to be exceptionally simple (or that working around this in the other reader of the var file is less feasible than I examine) I would not advocate changing Interp::save_parameters in the stable versions.

(as a historical note, it's possible that using the link syscall was shied away from in the name of portability [to Windows]. I don't care whether the LinuxCNC gcode interpreter is portable to Windows)

I am not a software guy, not even close. I can write some code on a basic to intermediate level as long as it includes fiddling with bits and bytes and a GUI is nowhere near the code. Check the components on the wiki for an idea of my abilities, not that fantastic.

That said: wouldn't some standard solution like for example SQLite be a much better solution for storage of data that is accessed by multiple clients of possibly multiple versions be a better idea? The problem with 'roll your own' solutions for read/write file access, client/server things, etc. is that making it work in a controlled environment is not hard, but making it work in the harsh outside world under all those circumstances you didn't even think of is much, much, much harder.
The same for things like the tool table; the current structure makes it not that straightforward to synchronise the tools between CAM and control. In my case this is only partially automatic and probably not robust at all.

If this just sounds like rubbish from someone who clearly doesn't know what he is talking about, feel free to ignore it.

To answer your question: yes something else could be better. The problem is finding someone with interest and ability to do it.
the problem isn't beg enough yet to force us to address it.

I pushed a fix for the offset widget to 2.6, 2.7 and master.
It will be available in the next bug fix release or on buildbot now.
Thanks for the report.

Chris M

To answer your question: yes something else could be better. The problem is finding someone with interest and ability to do it.
the problem isn't beg enough yet to force us to address it.

Hallo Chris,

I do not agree to 100 %.
IMHO you should place it as a issue, otherwise in half a year we all will have forgotten it.

Norbert

altering the tooltable is not for the faint hearted , amongst other things is is deeply rooted as is the interpreter and trajectory planner . so what you may think is an easy task , is far from easy . this is why some parts that you may find in mind are simple .

but in linuxcnc it is not their are actualy around 6 paths any instruction can take , and this is one area that is not well documented for this reason . and has expanded in time and evoulution .

syncing of tools should be easy between a cam system and linuxcnc , as this can be done as a server client
it's essentialy a mysql table ., i have a few tweaks to make this easier .

however i tend to leave the tooltable empty in linuxcnc and only use it for wear offsets ,as this is particular to a machine
and it's toolrack . i.e tools are not usually shared around machines in a shop .

and leave everything else to the cam program , sharing the same mysql data base

newbynobi wrote:

To answer your question: yes something else could be better. The problem is finding someone with interest and ability to do it.
the problem isn't beg enough yet to force us to address it.

Hallo Chris,

I do not agree to 100 %.
IMHO you should place it as a issue, otherwise in half a year we all will have forgotten it.

Norbert

I don\t think it is a bug - it's a limitation. (unless I'm missing what you are talking about}
being able to change offsets while paused and having a different way to save shared info would be good improvements.
I see little point in issuing feature requests - when someone wants it bad enough it will happen.
Any work that is deep reaching like this requires so much personal perseverance to get in to linuxcnc that it tends to
break motivation - linuxcnc is very stable because it tends not to change.
Machinekit was created because of this too. In that case it's almost the opposite problem now.

In fact Andy Pugh started a branch for tooltable storage that addressed one of these issues a few years back.
He got uninterested when nobody would give feed back to him about his work IIRC.

Luckily linuxcnc and machinekit are very usable even with the limitations!

Chris M