Visualizer orientation and other feedback

[dastultz]

Thanks for such a powerful tool!

• [x] The visualizer orientation looks wrong to me. The cube looks correct with the labels and +/-, but the axis colors do not agree. The preferences default to red for the X-axis but it runs front to back instead of side to side. The Y goes left to right (with respect to the face of the cube showing "Y-"). Also it's standard for the axis colors to be red for X, green for Y, and blue for Z. Fortunately this is all customizable so can be fixed in preferences. I think the default colors should be as they are in Fusion 360, Blender 3D, etc. and the axis labels for the color preferences should be fixed.

• [ ] I don't have limit/home switches on my machine so it's very useful to know how far the spindle will move in each axis, rather than the total workspace. So instead of or in addition to the overall workspace dimensions, I'd like to see the distance from 0, 0, 0 to the minimum and maximum distance on each axis.

• [x] Also there doesn't seem to be any preference for units. I work in inches and I'd like to be able to see the dimensions in the visualizer in Inches rather than millimeters. Perhaps the Jog controls and visualizer can take a common unit preference.

Thanks!

[winder]

UGS is rapidly becoming more than just a "Sender", so I think that a lot of this feedback is extremely useful.

I particularly like the idea of having the visualizer somehow represent the available workspace, it's something that I've been thinking about recently as well. But I'm not sure how it could be done in a robust way until the machine has been homed.

I wasn't aware of the axis mixup, I'll have to take a look at that.

For units you can set this in GRBL with $13=1

[dastultz]

On the units thing ($13=1), super, I was messing around with it "offline". Thanks!

[jahnj0584]

Agreed with the axis colours. The triad in UGS is wrong. Workspace, or the grid shown should just come from the 130/131/132 values, when a gcode dimension is large enough to show it. No point seeing the whole table on a 2" part....

His second point is already in UGS as the gcode dimensions. Thats your spindle travel path, not your part size.

[vMeph]

would be lovely to have visualization the same style has chilipeppr!!!

[dastultz]

Not sure I was clear on my idea for the workspace dimensions. I understand the rendered dimensions are that of the tool path, not the part. What I would like to see is how far the spindle moves from the origin in each direction. I've attached an illustration. 37.07 mm is the current rendering of the full X-axis traversal of the spindle. I've added +18.78 mm that indicates the spindle moves that far to the right of the origin and -21.60 mm that indicates the spindle moves that far to the left. This information will help me measure my setup to see if I have enough room to avoid crashing (it's a small machine).

[jahnj0584]

Well, you could just make your CAM origin in a corner instead.

You can also right click at the edge of the render and click "jog to". If it hits your edge, jog back the same value (or hit return to 0) and then zero your axis again. How ever much distance it lost, will now be offset.

On Nov 20, 2017 8:06 PM, "Daryl Stultz" notifications@github.com wrote:

Not sure I was clear on my idea for the workspace dimensions. I understand the rendered dimensions are that of the tool path, not the part. What I would like to see is how far the spindle moves from the origin in each direction. I've attached an illustration. 37.07 mm is the current rendering of the full X-axis traversal of the spindle. I've added +18.78 mm that indicates the spindle moves that far to the right of the origin and -21.60 mm that indicates the spindle moves that far to the left. This information will help me measure my setup to see if I have enough room to avoid crashing (it's a small machine). [image: ugs_dimensions] https://user-images.githubusercontent.com/4334042/33047838-da226f5c-ce25-11e7-95ea-4f2f6935b351.png

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/winder/Universal-G-Code-Sender/issues/813#issuecomment-345872756, or mute the thread https://github.com/notifications/unsubscribe-auth/AQlzDKahwnx8iEYQ9j4eS9S9D6tvOIBVks5s4hQbgaJpZM4Qkomn .

[dastultz]

The CAM origin is based on the needs of the machining process. I don't have limit switches so running the spindle into the hard stops is not an option. If my idea is not worth the effort, that's fine.

[jahnj0584]

You hit the hard stops before you run the program! It will self-regulate the origin for you so that it is safe to run without the limits.

On Nov 20, 2017 8:55 PM, "Daryl Stultz" notifications@github.com wrote:

The CAM origin is based on the needs of the machining process. I don't have limit switches so running the spindle into the hard stops is not an option. If my idea is not worth the effort, that's fine.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/winder/Universal-G-Code-Sender/issues/813#issuecomment-345880846, or mute the thread https://github.com/notifications/unsubscribe-auth/AQlzDCohc3Wx9fdWUGb7r9ZauAa1DjKLks5s4h9jgaJpZM4Qkomn .

[jahnj0584]

You can still use soft limits and check mode without limits by the way. Hit your hard stops, then reconnect. Your machine 0 is now 0,0,0 in your "hard" corner

On Nov 20, 2017 9:02 PM, jahnj0584@gmail.com wrote:

You hit the hard stops before you run the program! It will self-regulate the origin for you so that it is safe to run without the limits.

On Nov 20, 2017 8:55 PM, "Daryl Stultz" notifications@github.com wrote:

The CAM origin is based on the needs of the machining process. I don't have limit switches so running the spindle into the hard stops is not an option. If my idea is not worth the effort, that's fine.

— You are receiving this because you commented.

Reply to this email directly, view it on GitHub https://github.com/winder/Universal-G-Code-Sender/issues/813#issuecomment-345880846, or mute the thread https://github.com/notifications/unsubscribe-auth/AQlzDCohc3Wx9fdWUGb7r9ZauAa1DjKLks5s4h9jgaJpZM4Qkomn .

[dastultz]

As I said, I don't have limit switches. By "hard stop" I mean the table literally runs into hard parts of the machine and things come apart. I appreciate that a homed machine is useful, I just don't have it. Again, if my idea is not worth the effort, that's fine. I'm not really looking for workarounds.

[jahnj0584]

A simple screw in a Tnut can run as a hard stop. If you need switches I can mail you 10.

On Nov 20, 2017 9:09 PM, "Daryl Stultz" notifications@github.com wrote:

As I said, I don't have limit switches. By "hard stop" I mean the table literally runs into hard parts of the machine and things come apart. I appreciate that a homed machine is useful, I just don't have it. Again, if my idea is not worth the effort, that's fine. I'm not really looking for workarounds.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/winder/Universal-G-Code-Sender/issues/813#issuecomment-345883335, or mute the thread https://github.com/notifications/unsubscribe-auth/AQlzDGWg0Z8Eb5FN9NFhRYR74E37UX40ks5s4iK-gaJpZM4Qkomn .

[dastultz]

Please stop.

[winder]

Lots of people using GRBL don't have limit switches and have no interest in figuring out work coordinates. That's no problem.

@dastultz you're right I misunderstood your suggestion. This suggestion has been made before, but specifically about the Z-Axis (i.e. show the safety-height and cut-depth). Seems like it could be useful to some people.

I doubt I'll be able to implement this soon though. The suggestion from @jahnj0584 is probably your best bet for a short-term solution. If you right-click near the right/left edge it will tell you the X/Y coordinate of the mouse which is hopefully enough for you to get a rough idea about whether your part will fit on the machine.

[dastultz]

If you have any ideas about how it should be done, please post them here, perhaps I'll take a crack at it myself.

[winder]

@dastultz if you know how to use Java and want to give it a go, the visualizer has a plugin system for these sorts of extensions. Take a look at SizeDisplay.java for the piece showing the dimensions. There could be a new "dimensions from origin" flag which toggles between the current behavior and the suggested behavior.

[dastultz]

Great. I've got it building locally and I've made some UI tweaks already. I've never issued a pull request before, though. Maybe I'll start with something simple for practice.

[dastultz]

Hello, wondering what you think of this.

• Is the position of the new values good? Should they be to the left/right of the X-dimension line ("outside") or are they good just below the extension lines?
• Is it OK without the units present? Enough that the main dimension has the units?
• I'm trying to imply the "extreme position" of the spindle from the origin.
• Should this be a configurable option as an alternative to the current sizing as Will suggested, in addition to the current sizing as I've illustrated, or as illustrated but not configurable?

[winder]

@dastultz the location and lack of units on the new numbers looks good to me. I don't think this needs a flag we can just enable it

[mikegc51]

Hi newbi here, additional infomation to this discussion about visualizer having loaded gcode to allow jogging to work click x+ button yellow tool cone moves as expected to the right but then snaps back to work zero click y+ tool cone moves away (again as expected) and snaps back to work zero to change axis colour of left/right (normally X) change colour of Y (default blue) in tools/options/ugs/visualizer change axis colour of front/back (normally Y) change X (default red)

I have been using Rhino3d cad for over 20 years Fusion360 for 3 years and dabbled in many other cad's ,linuxcnc, they all respect the right hand rule for axis orintation and colour x-red, y-green, z-blue. The more I look on Google the more confusing myself and other people seam to get. I and i am sure many others would appreciate this standand in UGS

[Gonzose]

I have an issue that needs someone with more experience with UGS than myself. I switched to a new laptop that is much faster and responsive than my previous one. Since the switch the white cone in visualizer is out of alignment with the cursor. Usually is at the 10 o'clock position from the cursor. I like to use this cone hovered over the work piece to establish the coordinates and to position the bit. This way I can see how well the piece is sitting in relationship to the actual position the machine is going to carve. The question is: How do I calibrate the white cone or can I?

[breiler]

@Gonzose it will not help commenting on other (completely unrelated) issues to resolve your original problem (#2162). If you can't get UGS to work on your machine and if we can't identify the cause or reproduce the problem, we can't help you.

Fortunatley there are plenty of other senders for you to try: https://github.com/winder/Universal-G-Code-Sender/wiki/Software-comparison#gcode-sender

[Gonzose]

thanks, that's what I'll have to do. no problem.