Squished Preview

Hello

Does anyone have any ideas about what may be causing the preview display to be squished?

It certainly isn't a show stopper but it would be nice to have the aspect ratio of the display correct.

Another topic the use of the run from line function (or Gmoccapy button). I can select the line but when I try and run from the line many apparently random things happen.

TIA

John

Hallo John,

the small offset in the preview is known, it is a matter of rounding numbers in gremlin, the widget gmoccapy uses.
I will not work on that issue at this time, tool handling and some other stuff are more important.

What do you mean with run from line does random thinks?
Linuxcnc will not make any read ahead prior to starrt from the selected line, so if your code does have any spindle speed commands, or offset settings, etc, that will not be taken into account. That is the reason, why run from line is disabled by default, as I consider the LinuxCNC behavior dangerous.

Norbert

newbynobi wrote:

Hallo John,

Linuxcnc will not make any read ahead prior to starrt from the selected line, so if your code does have any spindle speed commands, or offset settings, etc, that will not be taken into account.
Norbert

Norbert, does that mean that if you have used work offsets (G54 etc) that will cause problems with run from line?

The issue at stake is recovering from a fault when cutting a nest of many parts on a plasma machine over a 2400 x 1200 sheet.

No, a G54 will not cause any problem, but if you set coordinate systems or offset with G-Code it can.

Norbert

Norbert

I home my machine to fixed switches for the machine zeros. Then I move (jog) the torch ( = spindle) (manual or MDI mode) to the work piece zeros (X,Yand Z) and set the G54 offsets to zero using the GUI buttons for the work piece zero location (offsets?). So in the gcode there are no offsets for parts or tools commanded. I do it this way way because it was how I was taught to operate a mill and I want to keep my soft limits working.

I should explain more about my run from line problems. What happens is I select a line (block) to run from with a G1 block (linear move as I have heard this is a known lcnc problem). Then when I press the start button on the GUI the code immediately jumps ahead (at least several blocks) to the next subroutine call and starts to execute the subroutine ( this is very confusing to watch because the code preview screen doesn't actually display the subroutine it just goes to the same line number in the mainline code for display). However the code only does part of the subroutine and then jumps to another place in the code (usually just prior to the subroutine call) this happens in an almost endless loop. Picture the pressing the start button and instead of the machine making the intermediate moves it jumps directly to probing the sheet, then until there is a probing error it is just stuck in a loop, probing the sheet retracting the torch again and again until there is a probing error or I get tired of watching the torch go up and down and e-stop the machine. I know this sounds very confusing but in plasma cutting one has many repeating nearly identical sections of code as each cut is done so it is easy to tell what the machine is doing even when the preview displays make no sense.

I don't really understand about the gremlin preview screen problem. I do understand that there are more pressing issues about tool handling ( I will convert my 1985 mill to lcnc once my plasma cutter is working in production). I find it odd that the back ground grid in gremlin preview has the correct aspect ratio but the part display does not. As to where the parts are on the display I just scale and jog for now to see them.

Thanks for building a great GUI. It is the reason I jumped into the lcnc pond instead of purchasing a commercial product. I can post any files you have time to look at, I just don't post them at random times because I am afraid that someone will mistake them for production quality code and dive down a hole with no bottom.

John

Hello

I have been doing some testing today without much success but have the following observations:
1. My machine is a gantry machine using the master 2.8-Pre branch. The mechanics work correctly.

[KINS]
KINEMATICS = trivkins coordinates=XYZY
#This is a best-guess at the number of joints, it should be checked
JOINTS = 4
and
[TRAJ]
AXES = 3
COORDINATES = X Y Z
LINEAR_UNITS = inch
ANGULAR_UNITS = degree
CYCLE_TIME = 0.001
DEFAULT_LINEAR_VELOCITY = 0.38
MAX_LINEAR_VELOCITY = 8
#NO_FORCE_HOMING = 1

2. I have both a Gscreen and a Gmoccapy configurations. The "squished" preview is actually a Y values times two. The measurement "rulers" and numbers are corrected but the plot is Y times 2.

3. I have tested by loading gcode files I created and ones in the distro. Both exhibit the same behavior.

4. When I run any of the sim configurations from the distro the preview is correct.

5. When I home my machine using either working configuration the Y axis travel is shown as being twice the distance actually traveled in the preview. The main DROs display the correct travel distance.

6. The aspect ration of the preview background grid is correct (1:1).

Ok, I know this isn't much to go on. Does anyone have a clue about what is happening or further testing to be done?

John

John, just a thought.

What happens if you open your gcode file in the Gmoccappy plasma sim? does it display correctly?

It could be something you've done in your GUI? It would be good to isolate that.

Also try opening it in axis gui.

This topic seems to describe the same behaviour.
forum.linuxcnc.org/38-general-linuxcnc-q...-y-axis-is-stretched
So what do you have in your ini file for GEOMETRY= ?

I am sure that you have
in your ini file as this gives an egg instead of a circle


the correct setting should be
which will correctly display a circle



the GEOMETRY= setting has nothing to do with joints and axes but configures the number of DRO's etc (and apparently the gremlin preview).

try it with this gcode file

Rod

You nailed that one. I thought that I had tried using just GEOMETRY=xyz during part of my testing but must have missed it.

So this looks like a case where the very "concise" docs can use a little updating for when a JA branch is used and when the JA branch auto configure script runs it should check this entry. A little better explanation about how the axis/joint definitions work together in the [TRAJ} and [KINS} sections of the .ini file and that they don't control what happens in the Gremlin Preview will be helpful as well. This was very confusing as the machine otherwise was working correctly.

BTW, I am not using any deadband with my current hybrid THC control at the present time. Beware that the way the deadband is implemented in the eoffset_pid there will be a step response as the arc voltage error exceeds the deadband. Now that I have a working THC I really should go back and try and get the eoffset_pid to work the way it was designed to be used instead of just using it to track the Z axis offset created when it tracks the Z axis movement during THC. The good news is that I have figured out but not tested a THC method that only uses hal components (a simple custom one) and doesn't require the external offsets branch. It does require synching the actual Z position at the end of the cut just like all the external THCs.

John