Probe Basic - is it possible to embed a GladeVCP tab in the QtVCP GUI?

I tried to embed Andy Pugh's lathe macros in my working copy if Probe Basic Lathe. I have to admit I am operating outside my knowledge and understanding, so I don't know if it doesn't work because of my ignorance or perhaps because it isn't compatible.

I posted on this thread and Andy was suggesting I ask in the QtVCP area:
forum.linuxcnc.org/41-guis/26550-lathe-macros?start=220#205935

I understand a new release of PBL is in preparation, so if I just need to bite my lip and wait for it, please just tell me to behave!

I'm guessing the developers are otherwise occupied preparing for this release.

I have a couple of issues right now. My lathe conversion is now 99% functional, albeit laid out on the bench for now. The next step will be to rip it apart and install it for real in the cabinet I've just bought. Before doing so, I'd like to convince myself I have a functional system by machining a test piece. This would be a major milestone to tick off at least.

I see that the lathe_pawn.ngc example file is missing a lot of info you'd actually need to run a real machine. I guess this is enough for running a sim but I'll have to create a proper version myself. For instance, there are no tool numbers or offsets specified and it is missing some of the initialisation lines you'd want to see at the start and end of the file. So I recreated my own pawn in Fusion and used the post LinuxCNC processor to generate a g code file. This specifies the correct tool (T4 in this case).

%
(1002)
(LATHE PAWN)
N10 G7
N11 G18
N12 G90
N13 G21
N14 G28 U0.
N15 G28 W0.

(PROFILE ROUGHING1)
N16 T4 M6
N18 G54
N19 M8
N20 G97 S1402 M3
N21 G95
N22 G90 G0 X45.4 Z3.
N23 G96 D2000 S200 M3
N24 G0 Z0.75
...etc

However, when I try to run it, I get a couple of errors:

• I have a couple of lines at the start specifying U and W coordinates
• I get a message saying it can't find the specified tool 4 in the tool library

This would be my first ever lathe program, so perhaps the U and W coordinates are fairly normal but I can't see anything in the Peter Smidt books about them. I can delete them, which gets rid of the error message but presumably the LCNC post produces them for a good reason?

As for the tool library message, this may be another symptom of the immaturity of the PB Lathe GUI. When I edit the library, the lathe.tbl file gets updated correctly, so T4 seems to exist and can be found / edited by other parts of the GUI. Is there any obvious reason I'd get this message?

The only way I can find to frig the system is to change the program tool number to zero(!). I guess I could do this solely for the purposes of running my one-off test piece although I don't know if the part zeroing macros would work with this method.

I'll see what state the PB Lathe GUI is in when I finally have the system installed in the cabinet and working again. That should buy me some time, otherwise I may have look into one of the other lathe GUIs. I'd certainly like to be able to use Andy's macros and obviously the tool library is a bit of an essential function that needs to be in place.

What is the choice of (functional) GUIs right now? Sounds like Axis and Gmoccapy?

I'll just point out that Qtpyvcp and Qtvcp are two different projects for linuxcnc widget display.
Basic probe is a qtpyvcp screen.

Qtvcp can display Gladevcp inside it, but its a bit buggy. There is a sample config for axis to test it.

Aha. Thanks for that info. That may explain the issue here. I'll spend some time during my cabinet build to look into GUIs and try to get a better understanding of what is happening.

I downloaded the latest PP from the Fusion 360 site, dated 3 weeks ago. Is there a better version?
www.vishay.com/docs/63064/sijh800e.pdf

It seems that U and W are generally parallel to X and Z in LinuxCNC - but not necessarily so for some reason. Elsewhere (eg Haas), U and W are described as a relative moves in X and Z, but generally only used for lathe.

I found this problem only arises if you select G28 rather than G53 for safe retract in the pulldown within the PP dialogue box.

This is perhaps complicated by the correct intent behind G28 retract move, which is technically a return to a reference position via an intermediate position. This may even be via a null relative movement - which you could specify as U0 W0 of course.

For completeness, here's the relevant section of the PP. If you select G28, you get U and W.

// format home positions
for (var i = 0; i < retractAxes.length; ++i) {
switch (retractAxes) {
....
....
case XZ:
words.push((method == "G28" ? "U" : "X") + xFormat.format(_xHome));
words.push((method == "G28" ? "W" : "Z") + zFormat.format(_zHome));
retracted[X] = true;
retracted[Z] = true;
xOutput.reset();
zOutput.reset();
break;
default:
error(localize("Unsupported axis specified for writeRetract()."));
return;

Conclusion - always choose G53 or edit your PP!

Hi all

I also have noticed the G28 U0 W0 trying to use the last fusion 360 post pro

Reading internet that seem to be normal for some machine like haas, but can you explain what is for using linuxcnc or if you think that is a bug ?

Br

andypugh wrote:

alkabal wrote:

I also have noticed the G28 U0 W0 trying to use the last fusion 360 post pro
 
I think that some lathe controllers use U and W for relative moves. They certainly shouldn't be inserted in G-code targetting a machine without those axes. 

 


 

I can confirm this.  Older Fanuc controls in dialect "B" and "C" (European-type) use G90/91 to switch between absolute & incremental.  In "A" dialect there is no switching, so an incremental move is directly programmed using U or W with no mode switch.

For a Fanuc lathe, G28 U0 W0 results in a return to reference point (tool change position) with no specific incremental intermediate points.

 

Thanks for reply

I know editing post pro is something not really hard but before doing that I think is better to ask if this is managed by linuxcnc or it is something wrong in the post pro.

I have also ask fusion forum and they reply :

On a Lathe the X can be U and the Z can be W, your LinuxEMC Control should be able to read and deal with either, these are not extra/different axis.

forums.autodesk.com/t5/fusion-360-manufa...m-p/10670061#M110801