Bridgeport Retrofit - keyboard input delays noted

Hi

So now I wonder if there is some magical commands to ensure LinuxCNC can use my newly purchased memory?

A 32 bit program can see up to 3.25GB approx so 2GB is not a problem.

You can run free in a terminal to see memory usage

Think I will wait until I hear back re. ArcEye comments.

Don't wait for me, I am fumbling in the dark as much as anyone

I would do what PCW suggests, but you dont need to vandalise your existing setup, just copy it to a new folder and work on that one.

First thing I would do, would be to run a standard sim (axis_mm or just axis if you use imperial) and run that as if using your machine.

If that works OK, the problem is not in rendering graphics or interpreting the code, it is further up the chain.
Strip your config until it has just has motors, switches and nothing more, then try again and so forth.

Very often the symptom is not a good indicator of the problem and this is the best bug tracking method

regards

Since the perfomance with 2G of memory was not noticably different I turned to my custom HAL. Last night I did as PCW suggested and took out the bells and whistles. I disconnected all of the connections to my machine control panel with the exception of those only absolutely necessary for operation.

I then went though my process which eventually typically causes the delay to surface. I went through my process about 20 times.

It is safe to say that the delays have disappeared. I think the next step is to methodically insert back into the HAL the functions which I disabled and check the resulting operation.

It may take a while. Wish me luck.
Mark

My bet is on your custom.hal file

At a quick count you have 38 realtime components running on the servo thread.
The chain of and, or, mux, oneshot etc is so convoluted I gave up trying to follow it

You could have a physical pendant with a MPG and axis / increment switches which only uses 1 x encoder and 1x mux4 component (what I have)
the rest are physical connections.

See how your tests come out

regards

ArcEye, you win your bet. The problem is definitely in the custom.hal. But not where I was expecting. The code to implement the ShuttlePro functionality is very convoluted. I have a logical flow diagram that fills one wall of my shop.

But the problem isn't in the ShuttlePro section of custom.hal. After verifying that the minimal custom.hal did not exhibit the symptoms I methodically re-inserted functionality back in and verified performance. The offending section controls how my 2 analog pots on my machine control panel handle FRO and SRO. From an operator point of view it sure is nice to be able to quickly grab a pot to slow the feed down instead of pointing and clicking or dragging.

I have further isolated the offending lines of code with the SRO/FRO sections. These lines provide the analog output of my pots to the input pins of the 7i77. I didn't go any further yet. Thought I might ask the experts before I dug around any more since it may be obvious to others where the root cause is.

Here is a cut/paste of that section with the offending lines commented out.

# feedrate override
loadrt scale count=3
loadrt conv_float_s32 count=2
addf conv-float-s32.0 servo-thread
addf conv-float-s32.1 servo-thread
addf scale.0 servo-thread
addf scale.1 servo-thread
loadrt near count=3
addf near.0 servo-thread
addf near.1 servo-thread
addf near.2 servo-thread
##
setp scale.0.gain 100 # X100 for increase resolution
setp halui.feed-override.scale .0008 # increased 100X over nominal
#net scale_input0 hm2_5i25.0.7i77.0.0.analogin0 scale.0.in near.0.in1
net frorealtos32 scale.0.out conv-float-s32.0.in
net fro conv-float-s32.0.out halui.feed-override.counts
setp halui.feed-override.direct-value TRUE
net fro halui.max-velocity.counts
setp halui.max-velocity.direct-value TRUE
setp halui.max-velocity.scale .00265

# spindle speed override
setp scale.1.gain 100 # X100 for increase resolution
setp halui.spindle-override.scale .0008
#net scale_input1 hm2_5i25.0.7i77.0.0.analogin1 scale.1.in near.1.in1
net ssorealtos32 scale.1.out conv-float-s32.1.in
net sso conv-float-s32.1.out halui.spindle-override.counts
setp halui.spindle-override.direct-value TRUE

I have attached the full custom.hal file.

Thanks for all of the assistance.
Mark

Thinking a bit more.

I think I will re-establish the 7i77 connection and disconnect the results of the scaling and converting process to the halui fro/sro counts pins.

As I mentioned earlier I know of another machine which exhibits similar symptoms. But that one does not use analog 7i77 functions. It does have fro/sro pots but they are provided through USB/hidcomp path.

The common element between the 2 different implementation is halui.spindle/feed-override-counts pins.

Hmmm.

Mark

...and the answer is.

The FRO and SRO pot inputs (after scale/conversion processing) are now disconnected from halui.feed-override.count and halui.spindle-override.count pins. No delays notice.

# feedrate override
loadrt scale count=3
loadrt conv_float_s32 count=2
addf conv-float-s32.0 servo-thread
addf conv-float-s32.1 servo-thread
addf scale.0 servo-thread
addf scale.1 servo-thread
loadrt near count=3
addf near.0 servo-thread
addf near.1 servo-thread
addf near.2 servo-thread
##
setp scale.0.gain 100 # X100 for increase resolution
setp halui.feed-override.scale .0008 # increased 100X over nominal
net scale_input0 hm2_5i25.0.7i77.0.0.analogin0 scale.0.in near.0.in1
net frorealtos32 scale.0.out conv-float-s32.0.in
#net fro conv-float-s32.0.out halui.feed-override.counts
setp halui.feed-override.direct-value TRUE
net fro halui.max-velocity.counts
setp halui.max-velocity.direct-value TRUE
setp halui.max-velocity.scale .00265

# spindle speed override
setp scale.1.gain 100 # X100 for increase resolution
setp halui.spindle-override.scale .0008
net scale_input1 hm2_5i25.0.7i77.0.0.analogin1 scale.1.in near.1.in1
net ssorealtos32 scale.1.out conv-float-s32.1.in
#net sso conv-float-s32.1.out halui.spindle-override.counts
setp halui.spindle-override.direct-value TRUE


So what am I doing wrong with my SRO FRO functions? Any ideas?

Mark

Now that I have the cause isolated to FRO/SRO hal code, Is my problem somehow related to the inherent issue using Axis and halui in attempt to control the same function?

www.linuxcnc.org/index.php/english/forum...her-with-halui#35672

How are others deploying external control of the FRO and SRO functions while using axis?

Mark

I was able to comment those 4 lines out successfully but when I start the machine I received error messages. File attached.

It appears to complain about line 2974 so I went in and commented that out also. After that the machine works.

The results of this are encouraging. My FRO and SRO pots both work as expected. The on screen sliders have no effect on either feed rates or spindle speeds. They do provide indications of the pot settings as you suggested they may. I did nothing to enable them as indicators by the way. They just follow the pot and provide numerical indications.

I will run this way and test further but preliminary testing shows I have no delay issues now.

One thing that is a bit odd. My screen used to show a 3 axis machine. Now I can choose up to 9. Someday I may be brave and add a 4th or possibly a trunnion table and need 5 but I doubt I will ever aspire to 9.

What did I do to enable that change? How can I change it back?

Thanks for the assist.

Mark