On Thursday 28 July 2016 15:23:41 Nicklas Karlsson wrote: > Then I am wrong I thought the hole *.hal file was parsed before > threads where started and then there is no execution order as in non > sequential VHDL or a Makefile. > I am not well versed in the thread startup, but what I can say is that regardless of the loadrt statement order, the order of execution is the order of the addf's in the hal file.
So with carefull attention to the addf order, you can read the encoder, take the action, and issue the correction to the hardware IN THAT SAME INSTANCE of that loops execution. By the same mechanism you can invert the order of some operation so that it takes until the next loop executes for the data to propagate thru to the next stage, in some cases killing as much as 10 milliseconds before the final result is known and can be used. In one instance I've now used in both the little monster and in the G0704, is to determine an average based on summing the results of all 4 edges of the quadrature signal by using a chain of mux2's to construct a fifo of the last 4 edges of the encoder values, using that for the feedback to the PID controlling the spindle. The secret is the clocking, if 2 consecuitive reads from the encoder are different, the fifo gets clocked thru and the new value written into the first stage, so at low speeds the fifo is frozen until it actually reads a new value from the encoder module. So its as effective as at top speed in quieting the step noise getting to the PID. This has the effect of reducing the noise in the velocity output by a /4 since the fifo's are fed to a pair of sum2's whose gains have been set for .25, and then those sum2 outputs are fed to a final sum2, which becomes the velocity feedback to the spindles PID. By reducing the noise, I was able to raise the PID's gains and have a pretty stiffly controlled spindle in both machines. And it seems that in practice, the spindle is taking far less of a beating than if the velocity was fed direct. > > > > Example: PID tuning parameters are pins. 99.9% of they time > > > > they are NOT connected to anything. A series of "setp" commands > > > > in the HAL file sets the unconnected pins to the proper values. > > > > > > Then they are connected and I expect setp happens before PID > > > is executed. The *.hal file is a kind of netlist and there is not > > > order execution, in sort of all of it are interpreted and > > > connected at once. Not exactly Nicklas, AIUI its done in the addf order _in that thread_. Ditto for ladder logic things. This is as its running, and may not be the order in which its encountered in the hal file. Two different critters. Initialization, and actually running. AIUI, the setp or sets writes to the memory location that the PID module references as it executes. This occurs during the init phase and is never done again unless you do it from the halshow utility while its running. So a setp to a modules controlling pin can be 400 lines down in the hal (files, could be more than 1) with no effect that I have been made aware of as it still gets done. However its a great help to me, when I am staring at the hal file in an editor, to have all the setp's immediately above the rest of the "net" list of what it is supposed to do. Much easier to visualize in this ancient wet ram. :) > > Actually there IS an order of execution. A *.hal file should be > > thought of as a script written in the HAL language. It is executed > > in order, and the order does matter. If you attempt to use "net" to > > connect to a pin before you use "loadrt" to load the component, it > > will fail. If you use "sets" to set a signal value before "net" > > creates the signal it will fail. > > > > > I expect *.hal file is interpreted and everything connected before > > > the threads are started. > > > > There is a hal command "start" which starts real-time execution. > > It is "usually" the last line in a *.hal file, but there is nothing > > about HAL that prevents you from making or breaking connections > > after the "start" command. HAL is designed to allow interactive > > use. I hope this helps. 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-developers mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/emc-developers
