Newbie- Osnap(?) and a request to BobCad

[Ed from NY]

Does BobCad have osnap?

I can find the ends and middle of a line, but not intersections, etc.

----------

I think that with v23 BobCad has taken a major step forward, but doing the drawing is still quite a bit of work.

Almost 20 years ago I and another 2 friends formed a company and wrote a 2D cadcam system similar to BobCad for punch press, laser and plasma. We worked with a CNC instructor who was a Trumph employee and did training for their customers. He was also very much hands on as he not only did parts himself, but was presented with all the difficult pieces their customers had trouble with. This was in the time when code neatness and size mattered because an operator was expected to edit gcode on the fly and smaller/smarter code meant you could have more programs "loaded in the machine". As all of these machines were used in production environments speed of execution was a big requirement as well.

This guru from Trumph used our software to do his job daily and all things he could think that would save HIM time, and save the machine time, he made us put in the program. As we sold the package to other companies with experienced gcode programmers we added the features they needed and to some extent their smarts.

Our company is long gone and the software probably lost

Still...

I think BobCad is in some degree missing that component in their development cycle. If you ask a programmer they might say, oh yes our software can do that, but if you listen to an experiecenced user they have the ability to tell you how do it better. To do this you need to establish a relationship with people in the field that are doing real parts all day long and give them the power, not to provide suggestions, but to define requirements. It is a painful experience for the programmers and for their manager(s), but it is a tremendous way to improve a product.

[Ed from NY]

BTW, found a bit of a cumbersome way of getting an intersection which it to break one of the lines.

May be there is a better way?

[BurrMan]

You beat me to it!

If you want to work with the intersections you can "Break" the entity. You can use Break many and choose the entire drawing if you want.

[BurrMan]

Another real easy way is to choose the Points Menu "Intersection".

This will place a point at any of the selected intersections which become snap points and leaves the original geometry in tact.

Points are very powerful. End, incremental, Intersection etc.

[BurrMan]

Ed,
Did you have something specific you are refering to? I mean, I just counted the steps to get intersection snaps and it took 5 clicks.

What would be better? Do you think the software should "automatically" create intersection points with all geometry? There would be downsides to this also that need to be considered. I have V23 loaded on a W2K machine with an ATI Radeon 7000 video card and it works fine!

Lets start a feature request thread! I'll try to come up with a few myself.

[Ed from NY]

Originally Posted by BurrMan Did you have something specific you are refering to? I mean, I just counted the steps to get intersection snaps and it took 5 clicks. What would be better? Do you think the software should "automatically" create intersection points with all geometry? ... Lets start a feature request thread! I'll try to come up with a few myself.

I think BobCad has enough elements that you "can do". Like we demonstrated with this example. However, I would venture to say it is missing a "productivity layer".

For example the intersections... an osnap that piked up intersections and other constructs would bring usability tremendously up. It is not something terribly complicated... I'll get into programing for a sec... in the windows environment frameworks usually have a call back/message that is invoked when you have spare cycles. That is how buttons get disabled/enabled and probably how BobCad find and highlights the underlying elements when you hover your mouse over things. Because of how the software behaves I'm going to guess that in the case of its current osnap the software first finds which element is closest and highlights it. Then only after you click the software will find the closest osnap point. That has 2 limitations... a) the user does not see the osnap locations and b) the osnap is limited to the information of a single element -- the shift key is a bit of a workaround for (a), but does not address (b). If you take that piece of logic and move it to the spares cycles happening when you hover your mouse you are now able to identify not the element, but the point you are osnapping to (and also highlight it to the user)... from there it is relatively straight forward to define a list of additional geometric locus to pick intersections, extensions and whatever... you use the same distance function you have now to finds the closest element, and ask the software give you not only the closest element, but also a list of all elements within "x" screen distance. From that list you figure the intersections and extensions and presto! Your osnap is very close to what AutoCad provides. It is a good size change... probably 3-5 person weeks, but it would be a huge improvement in the software and open a window for more sophisticated point finding.

An additional feature that can be tremendously useful is to pair osnap and/or point finding functions with all coordinate entry situations. For example, if you are entering a line by defining its begin and end coordinates... You could implement a feature where if you leave your caret (cursor) in the coordinate entry field and move your pointer (mouse) to the workspace it allows you to pick osnap points that get copied into the fields you are entering.

On top of that you can allow simple expressions like "+0.25" or "-7/16" to be appended to those values.

It would also be great to be able to correct mistakes by manually editing XYZ coordinates of lines, points and circles, that coupled with the 3 things above would be even more powerful.

So it is really not a matter of "can I do this" with the software, BobCad already has that. It is more along the lines of "how can it save me time" and little things (although some of the ones I described are not that little) can make a tremendous difference.

While we are at this, I'll drop a quick note about the post... it repeats things like speed and coordinates... our 1st versions of posting (back in the days) did the same thing... one client, who was a stick up for "code aesthetics" kicked us out of the plant. The fix was so simple... just keep a set of registers with the modal values and things that do not change by themselves, like where the tool is, feed speeds, RPMs, etc. When the the software posts the next operation you create a filter that gets applied just before you output that line of gcode. It cross references it with the set of registers and strips the redundant instruction components. It is very simple to implement and very resilient to bugs because the filtering does not have to worry about what the operation is really doing, just about identifying and stripping the redundant bits. It only took us a couple of days and everyone was so impressed because for them it was a big problem... this again is back in the days where code size was a biggie.

[BurrMan]

Hey Ed, Thats a great post!

The programming description for OSnaps makes sense, But There is something else to consider about this. BobCad is a 3D program and probably the "Most complicated" part to program is the "Display Mesher". These make and break programs. To write a good display mesher could take an experienced programmer 4 years or more. Alot of other companies may just license one that is battle tested, but there goes the price again. Real time OSnaps are a great feature, but its not just a bit of re-writing Some code. This would be a major overhaul area. Is the company re-writing things like this? We can both hope so! It's would be a great addition.

As for the commands input fields to interact with the viewport, this is a design point that ties with BobCads display mesher described above. It's been designed with 2 mode operation. The viewport is kindof "Turned Off/On" with regards to this. Thats why its "Pick Command, set, Choose item". It makes for less load on the system.

The Input fields do accept expressions! You can enter 2.364/2 for instance and the proper value will be entered. I'm not sure of the limitation of this, but you can enter tan(20)*6.143 and get the proper value also.

Some entities are modifiable after they are created. If you select the entity and right click and choose "Modify Entity", the edit dialoge will open to accept changed values. Some types arent supported with this, and I dont know the list of "Whats included".

These are great points that I agree with. BobCads viewport to me took a bit to get used to as its so different than other programs I use. With a bit of poking around, I'm getting the hang of it. Still have a way to go though. As a matter of fact, I've been contemplating a project to exercise my BobCad Modeling skills soon! If I ever get around to it, I'll be sure to mention anything I find.

Although it sounds like I am repeating "BobCad already does that", It's not my intention, I am in agreement with the jist of your post. Having a good discussion and soaking up your input.

The other thing to remember is I am not a BobCad employee and I dont have access to the code that creates it. Some of what I say may be erroneous! I'm pretty sure I have it right for the most part, but it also has to be taken with a grain of salt! (I'm just another guy in the forum)

Talk later?

Burr