qtvcp issues

These are set indirectly by the INFO library (lib/python/qtvcp/qt_istat.py).
I reads the INI file and if the INI settings are missing gives them default values.
In this case these lines do it:
This is so linuxcnc has a default jog rate.
May be I should code qt_istat to give warnings about the missing INI settings, but that could give a lot of noise...
I'll also point out that the INI settings are units per second and qtvcp immediately sets them to units per minute (that's the * 60).
If you don't want these set by the INI file then you can reset them in the handler file using the ACTION functions.
Chris M

I should probably give more information about the details of jog rate.
Because a screen is to be compatiple with either a metric or imperial based machine and that it can be in either metric or imperial mode - jog rate can mean alot of different things at different times.

To work inside this problem, the STATUS library holds the jograte etc in native machine units per minute.
So if your machine is imperial based but you are in metric mode - changes to jograte sent to ACTION must be converted to imperial.
at the same time if the machine is metric based and you are in imperial mode, changes to jograte must be sent to ACTION in metric units.
Now when talking of angular jogrates the units don't change in metric/imperial mode so you can send them to ACTION functions without worrying.
Currently, if you are not using the default widgets to set jograte, you must take care of these decisions your self. There are some functions to help - best to look at the action buttons code to see how it was done there.

If you decide to not follow this guide then it makes it incompatible with other widgets/other unit configs. (I am assuming you still will release this when your done)
In the end I believe we should probably make your jogging system into a regular widget and then no one else has to suffer through these details

I hope I explained it well - its easy for me to miss details.

On another note I have figured a work around for my error catching problem and added some more of the probing functions in. I see Versa uses remap for tool length probing and that I think is a problem. What do we do if the remap is missing and how do i check the remap is there and the right one...
It may have to be a non functional (possible hidden) option that the user must complete.
It should be some what testable (very very carefully!)
The location of the probe macros is probably a little weird at the moment though

Chris M

I have been working on getting my spindle functions working and I ran into a little problem with some motion pins not being available to my normal spindle control configuration. I had commented these out to get things running but as I progress and start activating those items it has become problem with getting my spindle control functions to work properly.

In my linuxcnc-dev configuration in the shop they all show up. I’m wondering now If this possibly a linuxcnc version related issue and if I need to add the qtvcp items into a standard Linuxcnc_dev configuration and then recompile to precede further. Documentation for motion.9 indicates that they should be available.

Here is a partial list of hal pins that cannot be accessed from within my .hal file.

Pin 'motion.spindle-index-enable' does not exist
Pin 'motion.spindle-orient' does not exist
Pin 'motion.spindle-orient-angle' does not exist
Pin 'motion.spindle-forward' does not exist
Pin 'motion.spindle-reverse' does not exist
Pin 'motion.spindle-revs' does not exist
Pin 'motion.spindle-speed-in' does not exist
Pin 'motion.spindle-speed-out' does not exist
Pin 'motion.spindle-on' does not exist
Pin 'motion.spindle-at-speed' does not exist

IF you are running v 2.8, its multi spindle now so there is a .0. in the pin names somewhere.

Rod is correct qt5vcp is behind master a bit but it did get multi spindle work in.

The pins also don't have 'motion' in the name anymore, look here for info:
linuxcnc.org/docs/devel/html/config/core...html#sec:motion-pins

Chris M

I have not been able to work on the project for the last week due to a trip I had to make to Anchorage and became ill shortly after returning. I hope to continue on the project some time next week.

I was able to implement the changes for the new required spindle commands and those all work fine now. I’m proceeding to work on the spindle control for my horizontal 4th axis which will use some code I developed about a year age but which requires some changes to the mesa driver to allow some parameters to become pins.

The spindle rates are fully adjustable via the sliders and can also be pre-set via the four buttons. Those are defined in the .ini file and buttons are name automatically. The jog increment buttons and there slow fast rate sliders work the same way.

4th axis control area and overall picture update.

I have read the documentation for additional spindles again and now have a second spindle showing up in hal show. I will configure this spindle for closed loop operation for position and velocity modes and orient. I did notice that the second spindle does not show up in halui.

I’m using the below code to control spindle.0 which works fine and wonder if qtvcp can handle routing similar code to control spindle.1

# set spindle 0 speed
def scrb_spindle_0_rpm_setValue(self,value):
spin_0_rps = float(value)/10000
self.cmnd.spindleoverride(spin_0_rps)
self.w.lab_spindle_0_rpm.setText(str(self.w.scrb_spindle_0_rpm.value()/100))

def pbtn_spindle_0_forward_toggle(self):
ACTION.SET_SPINDLE_ROTATION(linuxcnc.SPINDLE_FORWARD)

def pbtn_spindle_0_stop_toggle(self):
ACTION.SET_SPINDLE_STOP()

def pbtn_spindle_0_reverse_toggle(self):
ACTION.SET_SPINDLE_ROTATION(linuxcnc.SPINDLE_REVERSE)

looks like I haven't updated ACTION for multi spindle work yet.
I'm on a little vacation in Quebec at the moment but will be back at it soon.

Chris M