Advanced Search

andypugh wrote:

Yes, it's probably best to turn off CSS when threading. 

Andy,

I wasn't using CSS when threading.  Multiple attempts at tapping the same thread at different speeds resulted in different start points.

What I discovered (through @Aciera's help) was that caxis.comp interfered with threading/tapping, and that LCNC has a bug in G33.1 and G76.

forum.linuxcnc.org/38-general-linuxcnc-q...peed?start=30#317931

One way to use a sinking input with a switch-to-ground sensor is to put a resitstor (I would probably try a 10k, choose something that can handle the current that flows when connected between 24V and gnd, anything over 2.5k @ 1/4 W size will be OK). Put one leg of the resistor in the 7i76 input, and connect the other to 24V, The connect the leg of the resistor that is in the input terminal to your switch-to-gnd.
With the switch closed the voltage at the input will be zero, with it open the resistor will pull-up the input and set it true in HAL.

You can invert the sense of the input in the HAL layer to get the right polarity,

spumco wrote:

There is still an issue with threading in LCNC - thread start point varies with RPM - but that's not related to caxis.comp.

Yes, it's probably best to turn off CSS when threading. 

You are right, this does seem odd.

It might help to log the motion type and the probe input in Halscope, to see if there is some dither in the probe input. Is the stated 0.2s enough time for the target to leave the sense area?

If a couple of ms delay is acceptable then you could potentially add a software debounce to the probe input signal, if noise on the input is the problem.

1. Is there a means in Probe Basic to "hide" standard tabs?
2. How to specify the default tab when PB loads?  I'd like the Main tab to be the default, not Status.

Thanks!!!

Is there any feedback to the system to say what position thetoolchanger is in? Or does it rely on a single home sensor? What ensures that the stepper advances exactly the right number of steps?

BTW, great job on PB!

I don't disagree that in the long term, this might not be needed. But as all the EtherCAT drivers and IO are in a cabinet, it makes it much easier to troubleshoot, and as I finish the setup and fine-tune. The messages that are passed up to LinucCNC are almost useless.

Also, for future readers.

I am using the HAL widget (www.qtpyvcp.com/widgets/hal/index.html#hal-widgets), HalLedIndicator. The state of these are managed via the postgui.hal. The pin that qtpyvcp presents in the hal is named by the property pinBaseName (translated from the object name by default)

qtpyvcp.led-lcec-link-up = pinBaseName

Thank you guys! 
I have figured out what was causing the skewing and just finished fine tuning the system. Turned out that I had to tune the MAX_ACCELERATION settings for all axes. I have set P1.034-35 parameters in the servo drives as per the intended acceleration and deceleration times for the S-curve speed command. Turned out that this was not necessary and just reduced the time to the default value. The calculation for the desired S-curve in LinuxCNC per axis is quite easy - MAX_VELOCITY / (T_acc + T_dec).
Never crossed my mind that something so simple would be so hard to find. I did check the whole mechanical part - belt tension, rack and pinion wear. Nope, everything was in tolerance. The pinion did sweat me a bit because 4680mm are hard to measure. 
Something puzzling is that when I cut a square 50mm the dimension along the Y axis is 50.4mm but when I check with the dial indicator in incremental jog mode the steps are exactly 1,5,10 and 15mm. The scale of the axis seems correct. What could be the reason for that? Is there a way to compensate for it without tinkering with the scale? 

Best regards, 
Bozhidar 

I have the following code in the hadler vismach file. (a bit more in the file)

STATUS.connect('graphics-gcode-properties',lambda w, d: update_gcode_properties(d))

def update_gcode_properties(props):
    if props != None:
        print ("update update_gcode")
        property_names = {
                'x': "X bounds:",'x_zero_rxy':'X @ Zero Rotation:',
                'y': "Y bounds:",'y_zero_rxy':'Y @ Zero Rotation:',
                'z': "Z bounds:",'z_zero_rxy':'Z @ Zero Rotation:',
                'a': "A bounds:", 'b': "B bounds:",
            }


Based on graphics-gcode-properties I draw a block of processed material.

This code works, but only when I run it as a built-in qtdragon panel. I want to run the panel as a standalone window.
Currently, to make everything work for me, I run the panel twice, as a standalone window and as a built-in panel. I want to get rid of the built-in panel and run it only as a standalone window.

How do I modify the handler file so that it works as a standalone window?

It seems to me that "STATUS.connect" does not work in standalone vismach

Marek

I would say this, I would live with the stock ui for a bit, I think like most find the led's seem important initially, but in most cases once the machine is setup which can be done with halshow mainly, you will never visit the page they are on almost never. if you hit a limit, you get a pop up message, if you need an led for verification on a switch on item that isn't obvious I would say go for it, otherwise you are pretty much just creating a setup aid that halshow can handle much easier with a lot less work. just my two cents from developing and using PB for the last 7 years.

live with it and you will find the things that you need and the things that you can live without.

as for the how to, the qtpyvcp docs cover these things like widget rules etc. most mainstream settings and status items are baked in, anything custom you would have to sort on your own.

www.qtpyvcp.com/tutorials/widget_rules.html

Now i think of it, you're probably right. Maybe this is the case. What does imply for my setup / what should i look up so that i don't mess up the connection.

[EDIT]

I think i then have to connect it to GND and input right? (This is more safe, so i can test it first in this setup). I have this simple probe:

www.makerstore.com.au/wp-content/uploads...OOL-TP-V1-6a-NWM.png

Thanks. I was overthinking it.

For part of this I want to connect LEDs to hal pins. I have IO pins and based on their status high/low to enable the led. Much like Hal Show. I assume this is what HalLedIndicator is for? How do I "connect" the led to a pin? Rules? How are the hal pins named?

Examples of some pin I want to connect:
lcec.link-up
lcec.0.Z.din.1
lcec.0.Z.limit-neg

I found another problem with the MacroTab Widget related to the recent checkbox element improvement.

The checkbox element is not taken into account when numbering variables. All elements below the checkbox are shifted. #4 has value #5 etc. Two checkbox elements will shift everything below by 2, as in the screenshot.

Yes, the touch probe should be fine as long as it can be wired this way.

Note that many touch probes have a contact closure to ground, so be careful...
 

It seems the machine originally homed this way, but yes, you need to
guarantee the you are 2 index marks away from the end stop before
starting homing.