On Monday 19 November 2018 22:05:03 Jon Elson wrote: > On 11/19/2018 04:38 AM, Gene Heskett wrote: > > On Monday 19 November 2018 05:06:29 Nicklas SB Karlsson > > > > wrote: > >> What did you want to discuss with the addf function? > >> > >> I used it and think it works but what's more? > > > > We need a utility that detects out of order addf's, each > > of which then > > causes a one thread execution delay in the data traveling > > that path. > > WOW! This would be like a program that detects improper > word order in the English language! > While theoretically POSSIBLE, I think it would be quite hard > to do. You could look at the net commands, and figure out > which pins are outputs and which are inputs, and then kind > of determine what the flow is SUPPOSED to be, and then see > if the addfs execute the hal components in the same order. > But, it isn't so simple! Some hal components are not in the > "critical path" and so the order is much less important. > AND, for instance, all of the Pico Systems devices have an > INTENTIONAL "violation" of this rule. The reason is that > when the command to come out of E-stop is given, the modules > are not SEEN to be out of E-stop until the next servo cycle > reads the inputs. This allows the E-stop software-side FF > to not get sent back to E-stop immediately. So, if you > "fix" the addf order, you will not be able to come out of > E-stop. > > Finally, even if you were to find conflicts between net flow > and addf's, if you get the net wiring wrong, the proposed > tool would only make sure the addf's were consistent with that. > > So, using the hal show, halmeter and halscope tools, plus > understanding what is going on in the HAL layer, is the only > real way to get it right (in my opinion). > > Jon > > You may be right Jon, but it would quite a few printouts of the hal file to study up and check each path for such errors, and likely over a week to find and fix 2 errors. And maybe a rockhopper survey or 3, which takes about a day to print out and paste up here, so make it 2 weeks to find & fix 2, maybe 3 errors.
Probably the best way would be to trace thru each major path, writing down the modules name in the order is used in hal, and then compare that list with what you have in the addf stanza of your hal file. Bearing in mind that you don't want to get side-tracked by paths that diverge. A limit switch input one normally writes in the logic sequence, and that path is generally pretty short and that path is finished once its data has been delivered to the motion module above the motion modules own addf. Mark the addf's done to that point, take the next path, and group its addf's in the logic path order. Wash, rinse and repeat till all the addf's in front of motion are accounted for. Then do the same thing with motions outputs. But to be working with the current config, you want to start each new path trace with a fresh printout all around, rockhopper and all. I can see a ream of paper and $50 in printer expendables used once and binned, except for the last set that goes in the book for that machine. Both the Sheldon and the G0704 have by now, very complex hal files approaching 1000 LOC. TLM is at least 600 LOC. Not a job I'd relish unless something is all aglay anyhow. The only really simple one is the software stepping little HF mill, it and the Sheldon both benefit timewise by not using any PID's Oh, and I apologize for spelling Jon as Jom yesterday. Its hell trying to see when the glasses lens are so far off because I'm in the middle of getting my cataracts fixed. I didn't see that till the echo came back from the list-server. Take care, Jon. -- Cheers, Gene Heskett -- "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) Genes Web page <http://geneslinuxbox.net:6309/gene> _______________________________________________ Emc-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-users
