Advanced Search

not currently, but its on the list

yup, from memory the probe led is a good example, forgot about that one

M62 and friends need connections in HAL to have any effect. Do these connections exist? (motion.digital-out-NN etc)

As far as I know nobody has done this yet, but the change that allowed one to use a custom homing component was put in to support this type of scale.

How's your C coding?

www.linuxcnc.org/docs/devel/html/man/man9/homecomp.9.html

github.com/LinuxCNC/linuxcnc/blob/07cee8...nts/homecomp.comp#L4

However, I don't know if that is strictly necessary. I think that it _might_ be possible to craft a custom HAL component that outputs an encoder position and handles index_enable. This would take the encoder counts as input, and also manipulate the index_enable pin of the encoder counter. (I think it would be necessary to use the position-latching facility of the software or Mesa encoder. I _think_ you can set index-enable, which will zero the counts when the first index is seen, then re-enable index-enable and look at the counts-latched pin when index-enable resets on the second index. But I have not tried this.)

The component would then reset the index-enable that the homing system sees, and pass the correct position into the system. (Note that the "correct" position might be the inverse of the actual position, in some way. The position-after-index-enable is used by the system to calculate how far the current position is from the home position.

component inputs:
index-enable - to / from motion system
encoder position - from encoder counter
position-latched - from encoder counter

outputs:
index-enable - to manipulate the encoder counter
encoder-position - an offset version of the encoder position input

I do have a Heidenhain scale, but i have never done anything with it, and don't know if its a type with encoded index marks.

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