qtvcp issues

I have not felt like doing much coding work this last week so I downloaded the latest development version of linuxcnc-dev and integrated qtvcp into it to see if any major errors would occur while running my current development version of the 1xmill gui and it appears to be running ok with this configuration.

First from qtvcp_py2 I copied the /src/emc/usr_intf/qtvcp folder into Linuxcnc-dev/src/emc/usr_intf/qtvcp

I made a copy of the original /linuxcnc-dev/src/Makefile first and then I added the 14 lines that are associated with qtvcp into the original linuxcnc-dev /scr/Makefile via copy and paste from the qtvcp_py2 version into their proper locations.

Next I copied the /lib/python/qtvcp folder, and also the /share/qtvcp folder from qtvcp_py2 into identical locations of Linuxcnc-Dev. And also file /lib/python/qt5_graphics.py

Then after reviewing the changes in qtvcp_py2 /lib/python/hal.py and /lib/python/hal_glib.py files I also copied those into the latest version of linuxcnc-dev after renaming the original files. The hal.py file only has one one change at line 37 of the current version but the hal_glib file has many additions and a few changes. It was simpler just to copy the files over into their proper locations.

After this I recompiled and also made a new link for the qtvcp_plugin.py file from system:
/usr/lib/x86_64-linux-gnu/qt5/plugins/designer/python

To make a new link it will require deleting the old link that may already be there. Issue the command in a terminal opened as root in: /usr/lib/x86_64-linux-gnu/qt5/plugins/designer/python
Change routing in the below command as required:
ln -s ///home/cnc/linuxcnc-dev/lib/python/qtvcp/plugins/qtvcp_plugin.py qtvcp_plugin.py

It looks like /lib/python/rs274/glcanon.py would also need to be copied over to get qt designer to run and also show the hal widgets in the latest version of linuxcnc-dev.

Very nice looking screen you have there, fantastic work!

Kurt

while looking at file hal_glib.py in lines 204 and 205 it appears that line 205 may have a spelling error.

204 self.current_jog_rate = 15
205 self.current_angular_jog_tate = 360

But jog_tate appears in five locations in the file.

In ref to my prior post that mentioned, "I did notice that the second spindle does not show up in halui."

I was able to do further research on this and found a note by andypugh that there are two places that the number of spindles had to be entered in the .ini file. I had only done one. After adding a second one in [TRAJ]SPINDLES as SPINDLES = 2 the second spindle now shows up in halui.

My two entries in the .ini file are thus:
[EMCMOT]NUM_SPINDLES = 2
[TRAJ]SPINDLES=2

The first will show up in hal show under 'spindle' while the second will show up in 'halui'.

In my hal file I have the below which handles the first one listed:
loadrt [EMCMOT]EMCMOT base_period_nsec=[EMCMOT]BASE_PERIOD servo_period_nsec=[EMCMOT]SERVO_PERIOD num_joints=[EMCMOT]NUM_JOINTS num_spindles=[EMCMOT]NUM_SPINDLES

You _could_ keep it in only one place:
The reason for this situation (which I admit looks like carelessness on my part) is that "motion" (ie, motmod) is a real-time component and has no access to the file system. So all parameters have to be passed to it on the command line when it is loaded.

Other parts of the system (such as halui) _do_ have file system access and are able to access the INI file.

The complication here is that your HAL file is passing command-line parameters to motion from the INI file, so it looks like redundancy, but isn't really.

I have been playing with some spindle commands for my A axis spindle mode as below and they appear to generate the correct action as indicated by hal status and hal show.

def scrb_spindle_1_rpm_setValue(self,value):
spin_1_rps = float(value)/10000
self.cmnd.spindleoverride(spin_1_rps,1)
self.w.lab_spindle_1_rpm.setText(str(self.w.scrb_spindle_1_rpm.value()/100))

def pbtn_spindle_1_forward_toggle(self):
self.cmnd.spindle(1,400,1) # dir/speed/spindle numb

def pbtn_spindle_1_stop_toggle(self):
self.cmnd.spindle(0,1) # stop/spindle numb

def pbtn_spindle_1_reverse_toggle(self):
self.cmnd.spindle(-1,400,1) # dir/speed/spindle numb

I have not fully configured the system to actually get motor motion since the switching required to change from normal A axis indexer type configuration to spindle configuration requires qtvcp to be able to handle 4 joints/axis instead of the 3. Pushing buttons related to Axis movement just gives verbal messages mentioning 3 axis. I hope that this can be overcome without to much difficulty.

Qtvcp does not generate an error message when the number of joints/axis are more than it can handle.

I poked around in various files and all indications were that my axis/joint letters and numbers were correct. So I took a different approach and found my answer.

It turns out that the reason my A axis was not responding to jogging commands was this simple .INI entry: LOCKING_INDEXER = 1. Upon changing that to LOCKING_INDEXER = 0 qtvcp no longer gives me verbal warnings and the DRO indicates that there is movement.

Axis/joint letters and numbers generated in various files seems to indicate that QTvcp may be able to support 9 axis/joints. Is this a correct assumption or will there need to be updates to allow at least 5 axis/joints?

auto-mation-assist wrote: while looking at file hal_glib.py in lines 204 and 205 it appears that line 205 may have a spelling error.

204 self.current_jog_rate = 15
205 self.current_angular_jog_tate = 360

But jog_tate appears in five locations in the file.

Thanks ! i'll fix that soon

Chris M

auto-mation-assist wrote: I poked around in various files and all indications were that my axis/joint letters and numbers were correct. So I took a different approach and found my answer.

It turns out that the reason my A axis was not responding to jogging commands was this simple .INI entry: LOCKING_INDEXER = 1. Upon changing that to LOCKING_INDEXER = 0 qtvcp no longer gives me verbal warnings and the DRO indicates that there is movement.

Axis/joint letters and numbers generated in various files seems to indicate that QTvcp may be able to support 9 axis/joints. Is this a correct assumption or will there need to be updates to allow at least 5 axis/joints?

Locking index is a fairly specific type of indexing table. It cannot move unless unlocked, so (IFAIR) cannot do coordinated movement that includes the locked axis.
I'll have to read back some more to see what you are trying to do with the A axis, so as to diagnose the problem.

Chris M