Ah, I just realized that you’re probably talking about the behavior of the slider at the bottom. Yes, this is reversed from 2.2 to 2.3. Left to right is now “start to finish”. The resulting GCode will do exactly what you expect in terms of cutting top down. Sorry for the confusion. I wanted the slider to behave the same in all operating modes: CAM, FDM, SLA, Laser
Hi Stewart,
thanks for your fast answer 
I used to check “origin top” with 2.2, (un)checking it with 2.3-d11 changes nothing. So I tried again after reading your answer, not better. I’m running an Ubuntu 20.04 system, with the default Firefox 82.0.3, in case it could help you.
What did I tried to change (“origin top” is set) :
- don’t set the stock sizes, unchecked “offset” and “enable” checkboxes
- set stock sizes, no “offset” nor “enable”
- same tests (with or without stock sizes) with “offset” and “enable”
The origin stays always at the bottom of the stock. I’ve tried again with 2.2, it works as expected, the origin actually moves to the top whatever “offset” is set (no “enable” within stock for 2.2), just playing with “origin top”.
By the way, I’m much more comfortable not setting the stock sizes but relying on Kiri:Moto to set them with the overall sizes of the part. So I can home my CNC by simply moving the bit to touch the stock, quite the same procedure as setting Z on a 3D printer with a paper sheet, and the same slicing can be used with various stocks which are not exactly the same size.
I ran the same tests with Chromium (86.0.4240.198, the official snap from the Ubuntu repo), the cross showing the origin isn’t displayed and the behavior is the same, it stays at the bottom.
Regarding the slider at the bottom, I don’t use it. When I want to check the generated G-code either I use CAMotics to simulate the milling or I read the code myself.
@patrice please try using the new profile export (with workspace option checked) and email the results to sa@grid.space … I will try to reproduce it locally from your settings
thanks for sending the file. I was able to replicate the bug and fix it. D12 will have the fix live in 7 hours.
Fantastic
Thanks for all
Will be on the D12 release tonight. At least the Onshape default mouse mapping.
Yay! A small thing that reduces mental workload.
Mouse/UI related:
- In the default mapping, I missed middle-button-drag for zoom. I don’t have a mouse wheel unless I go find a mouse and plug it in. Admittedly, that may be not the most common practice, and I’ll probably be using Onshape mapping anyhow. I guess the point is: mouse wheel is far enough from universal to possibly warrant another way to zoom.
- In Onshape I use Z/z for zoom in/out. So of course I’d like to have that in KM. I get the “clear all settings” dialog … often.
Random feature-creep idea: making KM-in-Onshape aware of variables in the the part studio of an imported part could help workflow significantly, I imagine. Caveat: parts from more than one part studio.
Hi Stewart,
I tried your fixed D12 version a few minutes ago, it does work. That’s fine, thanks again.
1 Like
which variables and how would they be used?
see if the updated mapping (left click drag to zoom) helps
D13 is live. There are a few pending Firefox UI tweaks for tomorrow, but I am otherwise unaware of any material issues that would prevent a GA release Friday.
Please test and let me know if you find anything. The new export + workspace feature has proven to be a huge help in reproducing and solving reported problems.
Yes. That helps. Thanks.
which?: I was thinking more of general ability to reference Os variables by #name for KM parameters than of any specific variables.
how used?: the main/motivating use I’m thinking of is to keep CAD & CAM in sync for model features driven by tool diameter. As it is, that requires keeping two (or three or four if multiple ops) values in sync which is easy to forget. Especially when trying to get something done quickly; I broke a bit today for missing this once even tho aware of the need to get it right.
So that specific case would be entering an Os variable #name instead of a number as a tool flute diameter.
As ever, it’s great that you’re working on this.
A few things:
Save settings are getting routinely overwritten.
Expected: Settings saved on selecting
library->save->accept or edit name->ok
It looks like the named saved configuration last loaded from gets overwritten with the current configuration whenever a new config is loaded.
UI strangeness
This is frustrating because it’s so inconsistent that I can’t define specific circumstances or steps to reproduce. Every time I think I’ve got something figured out, I soon hit a counterexample.
Strange things:
- Sometimes some objects are hard to select. Clicking will not select the object. I try variations of double/multi clicking, changing view angle/elevation or zoom level or Onshape mouse mapping until something works and then I either don’t know which of a bunch of attempts actually made it work, or think I do but can’t reproduce it, or can reproduce it until I try to capture an example. It does seem that a portion of an object extending outside the stock box can always(?) be selected without hassle. (so I’d like to try disabling stock, but can’t reproduce the problem on demand…)
- Sometimes I can select/deselect an object but can’t ctrl-click a face to re-orient the object. I dropped .km export from one such occasion in discord.
- Sometimes I can select/deselect an object but can’t delete it.
- Tangentially related: with the pointer on a selected object, any of Left-, Middle- or Right-click and drag moves the object. That means mid- or right-click-and-drag functions are unavailable when the pointer is on a selected object. In the default mouse mapping that means can’t zoom or pan without moving the pointer away from any objects - which is a problem when a selected object fills the field of view and I can’t click outside the object to deselect it or zoom out or pan away to get to some background to click to deselect.
That’s not really an actionable bug report. If other people have said similar things, then it’s another data point to say such things happen.
Excess verticals in contour ops
In contour operations with “curves only” and “max angle” < 90deg, I don’t expect to see vertical surfaces contoured.
This shows some expected contours and lots of extra verticals:
In the other direction I would expect no contours at all, but get a similar bunch of verticals, and some horizontal segments where there no curve:
In this case I’d expect the obvious simple curves, but not any of the verticals or extra crossing “stitches”:
The extra cuts don’t really break anything but take time and mar surfaces that don’t need them.
.km in discord.
Bread-first roughing only?
Depth-first roughing has been unreliable in various ways, and for a few tries in D14 it looks like roughing does breadth-first only regardless of the depth-first setting.
That seems like a sensible thing to do for now.
Will that be the defined behavior for 2.3? i.e. can we turn on depth-first output and expect to get clean breadth-first rouging plus depth-first surfacing in the same export?
Climb/conventional milling preference?
I haven’t been picking on climb/conventional milling lately.
Do you intend for that preference to work in 2.3, or is that a 2.4 project?
Hi,
another UI issue : the stock shadow doesn’t lie around the part and the cross showing the origin is at the horizontal center of the part.
Settings : no stock sizes (0 for all), stock settings : offset = checked, enable = checked, output settings : origin center = unchecked, origin top = checked.
If “origin center” is checked, the cross moves to the upper right corner of the part. It looks like the origin is moved by (x/2, y/2) where x and y are the X and Y sizes of the part.
If the X and Y sizes of the stock are set, the part is aligned with the lower left corner of the stock.
Then if “origin center” is checked, the part doesn’t move and the cross moves to the center of the stock.
fixed in next build. this is a tricky topic.
I have experienced some of what you describe. It usually follows part rotations. I think it’s something internal to 3js and state. On my fix list.
working on it now. is a result of changes to allow contouring outside part boundaries. this was a complete refactor, so this was missed.
this requires more test models. the ones i’m using don’t exercise the full range of possibilities. as 2.3.x progresses, i expect this to improve.
possibly also a casualty of the great refactor. same answer as above. will work on cleaning up places that are not working.
I’m not able to repeat this in my current code base. Please send a profile export with workspace either via email or on Discord.
thanks
Hi Stewart,
I didn’t restart my browser (Firefox), just opened a new tab to access Kiri:Moto and save the profile, it’s now ok. Maybe a fix for something else that fixed this at the same time ?
Do you still want my profile ?
With a null size stock, “origin center” unchecked :
With a sized stock, “origin center” unchecked too :
If it’s working, then no need. I did fix a stock issue a couple of days ago.