encoder configuration help for threading

PCW wrote:

Yes, these need to be connected in your postgui.hal file with net statements

probably something like

net spindle-at-speed => gmoccapy.spindle_at_speed_led


the gmoccapy.spindle_feedback_bar connection in the postgui.hal file needs
a new signal in the normal hal file:

net spindle-velocity-feedback-rpm encoder.0.velocity-rpm

and then

net spindle-velocity-feedback-rpm => gmoccapy.spindle_feedback_bar

in the postgui.hal file


The index connection resets the spindle position to 0 when
LinuxCNC requires a spindle synchronized move (like threading)

wow you are great, now it is showing the rpm. the problem is that they are a bit unstable. however in the axis interface the rpm is stable.

Often a low pass filter component is added to the measured spindle
RPM to make it more stable

(Your Axis setup may also show the commanded rather than actual RPM)

PCW wrote:

Often a low pass filter component is added to the measured spindle
RPM to make it more stable

(Your Axis setup may also show the commanded rather than actual RPM)

 

I get a little lost there, I don't know exactly how to do that.

Somehow like so:
Set the "lowpass.0.gain" according to your desired frequency, more here: linuxcnc.org/docs/html/man/man9/lowpass.9.html

HansU wrote:

Somehow like so:

loadrt lowpass
addf lowpass.0 servo-thread
setp lowpass.0.gain 0.466
net encoder-out lowpass.0.in <= encoder.0.velocity
net spindle-velocity-feedback-rpm <= lowpass.0.out
net spindle-velocity-feedback-rpm => gmoccapy.spindle_feedback_bar

Set the "lowpass.0.gain" according to your desired frequency, more here: http://linuxcnc.org/docs/html/man/man9/lowpass.9.html

 

Thanks for your reply.
I've been looking at the link but the truth is that everything sounds Chinese to me: S I'm starting with linuxcnc and it's been quite an odyssey.
How can I know the frequency I need?
Those lines of code go in the postgui hal file or the main hal?

Yes the lines have to be in the postgui HAL file.

The filter frequency you get by trying out.  If you set a lower frequency the velocity display might respond slower. You can start by trying out the example values in the man page.

HansU wrote:

Yes the lines have to be in the postgui HAL file.

The filter frequency you get by trying out.  If you set a lower frequency the velocity display might respond slower. You can start by trying out the example values in the man page.

I get it. I'll try tomorrow and I'll tell you.

Thanks a lot.

HansU wrote:

Yes the lines have to be in the postgui HAL file.The filter frequency you get by trying out.  If you set a lower frequency the velocity display might respond slower. You can start by trying out the example values in the man page.

 I get this error and the program closes:

(gmoccapy:1374): GtkSourceView-CRITICAL **: 20:51:08.801: gtk_source_language_manager_set_search_path: assertion 'lm->priv->ids == NULL' failed
lowpass: already exists
custom_postgui.hal:5: waitpid failed /usr/bin/rtapi_app lowpass
custom_postgui.hal:5: /usr/bin/rtapi_app exited without becoming ready
custom_postgui.hal:5: insmod for lowpass failed, returned -1
1337
1370
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime

You already load a lowpass in mi-maquina.hal.

Change that toand usein your postgui Hal file

HansU wrote:

You already load a lowpass in mi-maquina.hal.

Change that to

loadrt lowpass count=2

and use

[code]lowpass.1

in your postgui Hal file

[/code]
 

now i am getting this error:(gmoccapy:6230): GtkSourceView-CRITICAL **: 19:43:45.173: gtk_source_language_manager_set_search_path: assertion 'lm->priv->ids == NULL' failed
custom_postgui.hal:5: Pin 'encoder.0.velocity' was already linked to signal 'spindle-velocity-feedback-rps'
6193
6226
Stopping realtime threads
Unloading hal components
Note: Using POSIX realtime