Hi, On Dienstag, 31. März 2020, 16:19:01 CEST Robert Ellenberg wrote: > Thanks for looking into this! I think state tags could solve your issue. I > wrote state tags years ago for PathPilot's fork of LinuxCNC ...
Don't know about state tags (yet) and did not know PathPilot either. After a quick look at PathPilot - its a gui for lathe isn't it? I might have a bunch of questions, when I reach state tags. > 1. UI status reflected the "read to" line, not the currently-executing > line > 2. When aborting a program, a user would expect the machine to be in the > state corresponding to the aborted line (not 10's or 100's of lines > later) So the concept of roles is wrong. It's like a C-compiler which does (part) of the linkers job, but so bad, that lot of compilations units fail, as the compiler did not have compiled a necessary module yet. >From my way of thinking, readahead of the interpreter is fine, as long as it does not affect the state of the machine (and fixture settings is machine property). The interpreter may only prepare all stuff for the task executor, but as with current f-word behaviour, it is completely wrong, changing values that motion or others will rely on. > A state "tag" just captures salient parts of the interp state (e.g. line > number, commanded feed / spindle speed, various G / M modes) and packs them > into a smallish struct. Most outgoing canon commands (including motions, > tool changes, etc.) are given a state tag when they are added to the interp > list. I guess, I first have to find the execution operator, i.e. the instance, that stops execution on single step or the like. > ..., but the G54 work offset is already changed, so the values will be wrong. Well, as I already stated: in my opinion the interpreter should not be allowed to change any machine setting. It's the task of the task executor to change G54 offsets or the like. I guess, as soon as the responsibility of tasks is fixed, many problems might have gone. > For example, PathPilot avoids putting all of the work offsets in the state > tag by making commands like G10 a queue-buster. On Dienstag, 31. März 2020, 16:38:31 CEST andy pugh wrote: > I think that any G10 or tool change should be a queue buster. I really > can't see any need to blend motion through tool or coordinate offset > changes. I agree completely! When I recap my work at cnc-machine, changing fixture-offset values is performed when the machine is halted and the interpreter is idle. Similarily probing is done without the interpreter knowing about gcode file. When I look at all these "bugs" - they have in common, that responsibility for tasks is wrong. I have started with adding line number to the structs. Then I search where to go next. Any hint about the task executor will be welcome :) On Dienstag, 31. März 2020, 16:38:31 CEST andy pugh wrote: > Accepting that would make it far easier to add-in the tool database > stuff, as tool changes can pop out to userspace to get the data. Andy, I realized a tool database in my app. As I have different Cams and (stil) different cnc-controllers, which all use different tool table format, I built a tool database with a superset of properties, where you can organize your tools hierarchically. The tool-manager has a pluggable export mechanism, so that I can generate tool tables for each cam and each cnc-controller. Adding support for new Cam is just a matter of implementing an export-handler. So in my app there is the tool-manager under settings, and the tooltable in linuxcnc-format at tool-button. I thought about generalization of atc too. I saw your datamodel and believe that it can be improved (based on responsibility). So if you're interested, we could talk about that too. cheers Reinhard _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
