Advanced Search

Thanks for your answer. I want to use a Push Button (action_button) with an led indicator, yes. But the led should follow a LinuxCNC status such as 'machine_on' e.g., not a HAL pin status. I have attached a designer screenshot of the property settings.

I have also tracked the switching of the led when I click the action_button for switching the machine on/off:
action: set machine_on to: True
++ flip_state: mach_on: True
   indicator_update, mach_on: True
** _update from connected press/release signals mach_on state=False
   indicator_update, mach_on: False
The last update step obviously turns the led off again after it was set on by the _flip_state function. So I prevented the _update function in indicatorMixIn.py from calling the indicator_update function (the code change in blue color).  Thus, the led remains in true-state according to the current machine state.
 
       def _update(state):
            print(f"** _update from connected press/release signals {self.objectName()} state={state}")
            self.setChecked(state)
            if self._HAL_pin is False and self._ind_status is False:
                self.indicator_update(state)

Don't know whether it could cause unwanted side effects. As far as I could see it works in my context.
A second point: Some code in my handler file causes the logger in indicatorMixIn.py to become active. Obviously it was not set up in this module, so an error message was raised. Adding the corresponding lines to set up the logger fixed it.

can you share whole content of your hal file? Btw you can check halui.spindle.stop pin in linuxcnc.org/docs/2.6/html/man/man1/halui.1.html

Geuss there's no way to get polar coordinates working on the x/c axis.

So the g10 l20 method looks to be the go, I'll probably try it tomorrow.  The idea is m106 --> brake off/ engage c axis/ read spindle position,  convert it to integer, subtract the integer from the spindle position, then multiply the remainder (0.***) with 360, g10 l20 to set the current c drive position to the spindle position. / if doing a drilling or milling fixed movement execute an m05 to turn on the spindle brake.  Then m106 to release the brake re-assert spindle position etc.

Doing milling on c axis is doing my head in, Im trying to write a cycle to do it, but tool radius compensation to do a square is complex and the calculations for the angular related spindle position in regards to the x position is quite a lot of trig.

Could you suggest if there is a solution for controlling LinuxCNC drives and other devices via standard CAN? Has anyone worked on such a task?

I understand that there is the EL6751 block, which controls CANopen. But I haven't delved deeply into whether there is a fundamental difference and how to configure it for regular CAN. Is this possible? Does anyone have experience with this?

I need help assigning the right wires  between the Mesa 7i97t  and SG-AS50 servo drive, I read the Mesa manual for the 7I97T and have seen  a  lot examples that deals with steppers. but cant seem to find information using similar servo drives that I have  

Thanks all for your help.
In the end I used the HAL to solve the problem.

So you ate using a momentary push button with an indicator led?
You want the led to follow a HAL pin state?
Maybe you could show an image from designer so I can see all the properties you have set?
It's quite possible I broke behavior from 2.8, lots has changed.

Yeah, youtube!
Sorry but i have 4 youtube channels, 3 instagram accounts, 3 e-mails, 2 whatsapp numbers, etc etc, and i use them sparsely.

Thank you, you must remember any of my comments on YouTube, I just have to thank you for everything you do, you positively impact the lives of many people.

Looks nice, thank you.
Edit:
Hmmm name, i know that name, did we chat on whatsapp or instagram?

I am Brazilian, for many years I have been following the posts here on the forum daily, some time ago I decided to build a table for plasma cutting, I built a table a little rudimentary, but very functional, using the parallel port, but encouraged by the posts here on the forum, I decided to buy a 7i96s board, although the import process took a long time, I just have to thank the people at MESA , after some time using the plasma, a colleague who owns a hardware store, wanted to buy it, as I had already started assembling a second table that was better made, I sold it, now I am finalizing the new table, thanks to you I have been successful and managed to generate results, (excuse my English, because I use the translator, unfortunately I could not learn English, and these days the rush does not allow)

Traduzido com o DeepL (www.deepl.com/app/?utm_source=ios&utm_me...gn=share-translation)

Since I'm new in this forum I'd like to show the background for my question. We have an old Taiwan drilling/milling machine upgraded with stepper motors and encoders on the axes. Axes motion and spindle (on/off, fwd/rev) are controlled by LinuxCNC 2.8.4 on Debian 10 using a Mesa 6i25 card. Later, some approaches adapting the GUI (AXIS) to fit the personal workflow had taken place. Quite soon the choice came to Qtvcp. Starting with the tutorial in the docs I set up a GUI according to my taste. For me it worked fine.

Now I want to switch to Debian bookworm using LinuxCNC 2.9.3 and, since I wanted to do minor extensions in the widgets, also want to have a development implementation cloning the git repository. The migration from 2.8.4 to  2.9.3 was basically not a big deal, only some conversion from python2 to python3 had to be done.

But, and that's my question, the behavior of the action buttons obviously has changed. The indicator LED of these buttons are only highlighted as long the buttons are not released (at switching on). The indicator function is referred to the status e.g. 'state_on'. The properties in the designer are set accordingly, i.e. 'indicator option', 'indicator_status_option' and 'is_on_status' e.g. are set to 'True'. The same behavior is observed in 2.10.0.pre (master c7b2655). I spent some time looking at the source code of action_button.py and indicatorMixIn.py. In the latter I came to the function 'connectSignals'   

def connectSignals(self):
        def _update(state):
            self.setChecked(state)
            if self._HAL_pin is False:
               self.indicator_update(state)
            # if using state labels option update the labels
            if self._state_text:
                self.setText(None)
            # if python commands call them
            if self._python_command:
                if state == None:
                    state = self._indicator_state
                self.python_command(state)

        if self.isCheckable():
            self.toggled[bool].connect(_update)
        else:
            self.pressed.connect(lambda: _update(True))
            self.released.connect(lambda: _update(False))
        _update(self.isChecked())

Obviously the indicator state gets set to False as soon as the button is released. Thus, the value previously set correctly by self._flip_state(..) gets overwritten. Shouldn't be the 'if'-statement, checking for the HAL-pin-option in the _update function also be extended to check for the status-option according to the _safecheck function in the action_button  code? Or do I mixing things with my very limited insight to the workflow of the code? At least, switching off the call of 'connectSignals' brings back the behavior known from 2.8.4.
Has anyone also observed this kind of behavior? And, just to mention, setting the button 'checkable' works as expected.

try to compare the feedrate between the test and the exported code, the linear movement is probably fine as far as the ‚‚F‚‚ values ​​at the end of the command lines starting with G1 G2 G3 are concerned..however if the same feedrates also have rotating axes I think it will slow down machine. because linear axes imply distance/time and rotary axes deg/time.

I am a beginner in Python, but I have fixed some problem (I think so) in the Bogdan's version, and I see that editing a parameter and closing the "calculator" make ncam crash cause a -11 error (segmentation fault).
I think there is something wrong related to gtk on closing dialogs.
The crash happens (on my computer) when the custom do_start_editing() function returns to the caller (I think that's gtk).
I have my modified version, if someone want to give it a try...