qtvcp issues

auto-mation-assist wrote:

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.

Can you quote the error messages?
How are you doing jogging? keyboard? jogging button?

Chris M

I pushed a fix for the spelling mistake and updated the ACTION function to include optional spindle number in them.

I can rebase qtvcp on current master but it would make updating for you a bit of a pain. It'll happen eventually.

Chris M

Happy new year everyone.

I have been busy these last three weeks but continue to work on my gui project as time allows. I plan to upload what I have completed so far after I draw a layered map of the gui that allows cross referencing buttons and other items to specific areas and layers.

Current picture is attached. of the main panel.

Looking great!

Chris M

Hi all

New here. Sorry for the quick digression from the main topic. I have a keen interest in getting involved with some GUI development as it will also help me in my professional work, and the qtvcp branch really apeals to me. The work I see Johannes doing really looks fantastic and is a nice clean design IMHO. From what I understand, Chris is more involved with the widgets themselves than the actual GUI frontend. Is there a concerted effort to work on one version of the frontend or is it still a bit fragmented where everyone is having their own stab at using the widgets and customising accordingly? My searches are taking me down many rabbit holes
I would prefer to assist where the need is to drive the project to a production ready release if that makes sense?

Craig

gibsonc wrote:

Hi all

New here. Sorry for the quick digression from the main topic. I have a keen interest in getting involved with some GUI development as it will also help me in my professional work, and the qtvcp branch really apeals to me. The work I see Johannes doing really looks fantastic and is a nice clean design IMHO. From what I understand, Chris is more involved with the widgets themselves than the actual GUI frontend. Is there a concerted effort to work on one version of the frontend or is it still a bit fragmented where everyone is having their own stab at using the widgets and customising accordingly? My searches are taking me down many rabbit holes
I would prefer to assist where the need is to drive the project to a production ready release if that makes sense?

Craig

Hi Craig.

My involvement with QTvcp is really for building the infrastructure so users/developers can build screens without having to reinvent the basic building blocks each time, while also insulating builders from some of the idiosyncrasies and small changes to linuxcnc.
The screens I built are really for testing and concept Ideas - though if someone wanted to polish them that would be great.
Johannes has said he would offer his finished screen to be included with linuxcnc, which is wonderful.
Norbert of Gmoccapy fame has indicated he is interested/started a new screen based on qtvcp.

There is a similar-in-purpose project coded by Kurt (Hazzy) originally roughly based on qtvcp code.
By the screen shots it looks fantastic and Knowing Kurt's work (he added code to qtvcp), it will surely work well.
it's called PyQtvcp. That project is separate from linuxcnc.

There is also Brenda's concept work on a screen for linuxcnc. I have a test screen roughly based on her concepts, but again really just to flesh out some of her control ideas. AFAIK now one else has coded anything.

There is also another project that is building a screen using c++ I think - I don't know much about it.

So the choice seems to be qtvcp , pyqtvcp, or starting your own project.
I'm biased or course but qtvcp will be included with linuxcnc project which is convenient.

Please unless you have a really really good reason, don't build another screen project.
Linuxcnc IMHO is really having a problem of too few developers, so creating competing projects makes that worse.
but yes please build a screen or help with one of the existing screens.

Chris M

Just a note on the screen I'm working on. At the onset I wanted to build a screen using Labview since it allow me to use diagrams instead of code for development, and also that I'm much better at using Labview than using Python. The problem there is how to link into Linuxcnc effectively and have access to everything via a network connection to the Labview gui. For me the network connection on the Linuxcnc end became a problem that I still need to resolve.

In searching I found that Qt offered the best alternative for me right now so I proceeded on doing development work. My use of QTvcp is somewhat different than Chris has envisioned because I like to do most of my own coding within the handler and minimize the use of pre built widgets. The graphical part of laying out a gui is fairly easy and the XML file generated can be edited manually, but interfacing it and getting all its features to work is more difficult.

So I see two ways that QTvcp will be used and the core of QTvcp needs to be handle both ways effectively. One way is with maximal use for the pre built Widgets and the other is the use QTvcp a a building block and do most coding within the handler itself. The gui that I laid out can be used either way with some changes from hal items to action items. The second way is well suited for customization and development work and is the way I prefer.

I did find some software that will allow me to make some maps of how the gui is layed out and the sections and layers within it. I hope to be able to upload my latest code soon but I need to do more work on the section that I’m working one new which is the loading of the Inch and mm increments tables for liners and angular jogging. Some new items have to be added to the .ini file or a custom configuration/preferences file. More will be needed later for handling button selected macro files. The below are my test values.

A issue developed yesterday that I will describe in a separate post.

[X1GUI]
POSITION_MAX_RATE = 50
POSITION_SLOW = 10
POSITION_FAST = 25
POSITION_CMD_0 = 'G01 X0 Y0 Z0 A0 F5'
POSITION_CMD_1 = 'G00 X1 Y1,Z1 A22.5 F10'
POSITION_CMD_2 = 2
POSITION_CMD_3 = 3
POSITION_CMD_4 = 4
POSITION_CMD_5 = 5
POSITION_CMD_6 = 6
POSITION_CMD_7 = 7
LINEAR_INCR_INCH = 1.0000,0.7500,0.5000,0.2500,0.1000,0.0750,
0.0500,0.0250,0.0100,0.0075,0.0050,
0.0025,0.0010,0.00075,0.0005,0.00025
LINEAR_INCR_MM = 25.400,10.000,7.500,5.000,2.500,1.000,0.750,
0.500,0.250,0.100,0.075,0.050,0.025,
0.010,0.0075,0.005
LINEAR_INCR_INCH_DEFAULT = 0.2500
LINEAR_INCR_MM_DEFAULT = 10.000
LINEAR_MAX_RATE = 50
LINEAR_SLOW = 3
LINEAR_FAST = 10
ANGULAR_INCR = 0.1,1,5,10,15,30,45,60,75,90,105,120,135,150,165,180
ANGULAR_INCR_DEFAULT = 45
ANGULAR_MAX_RATE = 30
ANGULAR_SLOW = 20
ANGULAR_FAST = 30

Yesterday while doing some work on switching between inch and mm unit mode I ran into a problem that I think was caused by some code that I had placed in the ini file just to have something to load. I suspect it may have been this but I could have nothing to do with it.

[X1GUI]
POSITION_MAX_RATE = 50
POSITION_SLOW = 10
POSITION_FAST = 30
POSITION_CMD_0 = ('NAME0),('G10 L10 P{0} {1}{2}".format(self.stat.tool_in_spindle, axis, value)')
POSITION_CMD_1 = ('NAME1),('G00 X0 Y0 Z0 A0 F10')

When looking at the .ni file after my problem developed In noticed that everything after
'POSITION_CMD_0 = (' is being displayed in pink with the exception of G10 L10 P {} {}{}

So obviously a damaged ini file.

Now the problem is that the x1Mill gui will not allow the screen to become enabled. Only the Estop, power, help and exit buttons can be pushed. The power button will not turn the machine on. If I modify the handler code to disable the button disable feature then when pushing the power button I get a voice message saying estop is active. But this is a internal QTvcp estop and not an actual estop condition.

I suspect based on a alarm message I found in the terminal that was generated from one of my own error catching routines that there is not a valid 'inch or mm' unit value being detected by QTvcp itself. I disconnected my network into the machine and successfully ran gmoccapy and qtvcp (earlier version) from its normal network connected computer. Thus no issue with the machine itself.

In looking at the grid display that is displayed in the graph area of gmoccapy i noticed that the grid is canted like the machine axis are skewed and suspect that this could be the cause as to why most of the gui is being kept in a locked out condition. The skewed grid lines make me wonder if QTvcp can handle such a condition is this is real and how to get un-skewed. I have never seen the grid lines skewed before. Picture below.