Hi Reinhard, We have added line numbers to each struct returned from rs274.
I have asked one of my colleagues to update that to master branch and publish it. Regards, automata On Tue, 31 Mar, 2020, 8:37 pm Reinhard, <reinha...@schwarzrot-design.de> wrote: > 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 > _______________________________________________ Emc-developers mailing list Emc-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-developers
