qtvcp issues

I’m having a bit of a problem trying to figure out what’s going on under the hood of qtvcp.

If I use old action buttons for jogging all is good and happy but if I change these buttons to 'newly generated' simple hal push buttons the buttons do absolutely nothing other than the fact that I can see them changing colors on the screen when pushed. They will not enter into their 'def' statements either when the buttons are pushed.

The buttons I have been trying out have not been programmed to do anything other than print out a simple message to the console and they will not do that.

The buttons are activated and the commands below work fine but that’s about it from what I can tell:

self.w.pbtn_jog_neg_x.setEnabled(True)
self.w.pbtn_jog_pos_x.setEnabled(True)
self.w.pbtn_jog_neg_x.setEnabled(False)
self.w.pbtn_jog_pos_x.setEnabled(False)

I suspect a recent change may be causing this problem.

I ran into this when I wanted to do some testing of direct jogging control via hal pins.

Have you pushed the changes to your repo, so I can test ?

I've finished my work marathon should should be able to spend more time on the project.

Chris M

Great. I worked 12 hour days for a great number of years alternating between day and night shift about monthly.

I would have to see what would be needed to push what I have been working on. Its running on my actual machine controller for testing and uses its .ini and hal files. I will need to see if it will run in sim mode.

Can you tell me how to write and read to the hal pins that qtvcp makes, not the ones that I make in the handler? The ones I generate in the handler files are ok and I can read and write to them but I don’t how the format to to access the others. The ones that qtvcp makes all have the prefix of the gui name which right now is 1xMill_P_xxxx . P meaning that probing is included inside the handler file.

I forgot to add that I did a complete built of Linux-Dev today to eliminate any possibility of and issue with not being up to date. I had also copied some buttons for testing and got the same result with them not acting normal.

Its just the buttons that are in the top part of the picture below that are not responding after removing the Action buttons and replacing then with hal PushButtons. I think this is very arrange. Very frame is enabled as are the X, Y and Z buttons.

I should also mention that I have been unable to write values to the Step and Rate displays since this became a problem several days age. The five lower buttons work fine. I have not seen anything unusual in the layering in the qt designer.

I did do a git pull some number of days before making this change to PushButtons for testing. Cant recall exactly but may have been around five days ago.

auto-mation-assist wrote:

Great. I worked 12 hour days for a great number of years alternating between day and night shift about monthly.

I would have to see what would be needed to push what I have been working on. Its running on my actual machine controller for testing and uses its .ini and hal files. I will need to see if it will run in sim mode.

Can you tell me how to write and read to the hal pins that qtvcp makes, not the ones that I make in the handler? The ones I generate in the handler files are ok and I can read and write to them but I don’t how the format to to access the others. The ones that qtvcp makes all have the prefix of the gui name which right now is 1xMill_P_xxxx . P meaning that probing is included inside the handler file.

The HAL pins from widgets were never intended to be manipulated directly.
That said it is possible, but likely the code would be slightly different for each widget.
eg for push buttons:
state = self.BUTTONNAME.hal_pin.get()
You wouldn't want to set a button pin as then it wouldn't match the button state.

I don't understand why Versa probe uses HAL pins. In my widget version I removed that.

Chris M

I can not replicate your button observations.
Can you modify your sim screen to cause the error and push to your repo?

Chris,

Ok I will try to do that today but may not have the time. I suspect now this may only be a local problem here and that I need to do a little more work to try to figure this out.

I like the fact that you were able to eliminate the need for pins in the Versa code. If I can figure out the changes required I would like to built a version of that also. I Will push the latest changes to the probing gui soon but this may not help you a lot since I use different names for buttons and displays to clarify those items just a bit. It will likely need a lot of search and replace work for the names.

On the use of pins:

I think the use of pins gives an easy way to code things and offers a great deal lot of flexibility for the user. Flexibility in my mind is very important since many LinuxCnc users will always want to add special functions in a fast and easy way without involving the programmer and asking for modifications to the main code. I consider pins to be similar to global variables. It offers a way to route data to suit the users requirements.

In looking at the hal components I generated within my handler file I noticed that they never enter a ready state. I wonder if they need to be placed in the 'bin' folder somehow so they can be found. There was some mention of something like that in my internet search for a answer as to why 'ready' never occurs. I have added some pictures of how I generate the pins are below in the hope of solving the never ready problem. Adding the below to the postgui hal file does not help.

loadusr -W x1_jogging
loadusr -W x1_tool_measure
loadusr -W x1_probing


In your file 'qtvcp' located in the bin folder there is:

##############
# Build ui
##############

#if there was no component name specified use the xml file name
if opts.component is None:
opts.component = PATH.BASENAME

I would like to enter a name here but have no idea of where to put such a name.







My editorial comment: I think we all know that LinuxCnc is lacking a modern network interface and that this has resulted in everyone being forced to find ways to interface modern methods to poorly documented ancient code that relies on NML.

Chris,

You mentioned,

"The HAL pins from widgets were never intended to be manipulated directly.
That said it is possible, but likely the code would be slightly different for each widget.
eg for push buttons:
state = self.BUTTONNAME.hal_pin.get()
You wouldn't want to set a button pin as then it wouldn't match the button state."

Since things like true state text and true state cmd are writeable from self.w.'button name'. xxx in the handler can those be pulled out by commands similar to:

state = self.BUTTONNAME.hal_pin.get_true_python_command()

Or is it only for True/False states for the buttons.