CAD/CAM discussion forum > 3D CAD/CAM > A dream CAM browser I

A dream CAM browser I

    
  Subscribe Topic

Rank: 1

Dan

Newbie

posts: 0

Registered: 2002-8-26

Message 1 of 11

 A dream CAM browser I
27-07-2004 09:52 . am   |   View his/her posts only
Dear Gents,

I bother you with a thread about a dream CAM browser that should offer the ultimate functionality being as friendly as possible.

Of course this thread is hear because I want to read your opinions about this thing.

I'll start with some of the fundamental mechanism inside the browser without being concerned about rigid framework that is a highly subjective issue and will be the subject of second post:

- Drag and Drop
- Cut, Copy and Paste for any type of node
- Genuine chronological organization. This is took as granted the browser will be a reflection of milling process.
- Polymorphic operations. You generate an operation Cut&Paste and change the operation type from Z Level to Lace reusing 95% of its modifiers.
- Genuine template based. You can select any number of operations and save them in a template. Or you can import any template from the disk. Templates can be free editable in any editor or XML editor because they will be in XML format you can quite cut something paste in an editor edit cut from editor and paste in the browser.
- Full Dynamic interface if a new CAM engine richer in functionality is available this will questioned about its functionality and the host application will use the new extra functionality.
- Comment nodes. Give you ability to add comments node in the browser.
- Active Nodes. These nodes are used to write commands in CL file and/or to change some milling status and/or trigger a report and/or CL generation etc, etc. Example can be: ToolChange, Coolant{ON, OFF}, FrameChange, Zcorrection = 10, CLOut, ReportOut, etc. Active Nodes are fully customizable you should be able to create you own Commands that will be mapped lets say in first instance in custom output in CL file.
- Aggregate Nodes. This will be helpful to group together various other nodes being the core of reuse. Here you can organize data however you want give it a meaningful name and store it to disk or you can collapse it to dont be bothered for a known, custom, methodology.
- Dynamic parameter on the forms (actually will be in first instance simple customizable nodes in the tree). This means you can fully customize how rich or spartan the parameters set will be on the tree if you decide you never need to use pillow optics or all the tweaking parameters or roughing behavior for finishing cycles you can disable this parameters.
- Meaningful and scalable defaults. This is very important all parameters that are expressed as distances by default will be a factor of step or tool radius or diameter for example to increase their intelligence to understand the process where they are introduced.
- All parameters that have distance meaning should have multiple ways of input like: absolute value (static) or % of Tool, % of Step, % of Tolerance, Factor of Tool, Factor of Step, Factor of Tolerance, etc.

Now the forms for Data Base like objects like: Tools, Holders, Materials, Machines, etc should all be Grid based to support native cut and paste, import, export in excel and XML format, to support easy and standard sorting and filtering.

Rank: 1

OldForumPost

Newbie

posts: 0

Registered: 2012-1-14

Message 2 of 11

30-07-2004 05:25 . am   |   View his/her posts only
Hello QM Master,

I have absolutly the same opinion about that. The GUI must be completly dynamic during the work. If you change the tool from a calculated tool path the old tool path must deleted. If the tool path is used as a Ref Operation the other operation must be also updated and the old tool path must deleted etc.

I would like to make also copies from features like profiles etc. to modify or change some things for other operations. Options that are not available for a setup should be greyed out.

If you change the step type the step value should also calculated to the right value. One example your step size is 0.5MM your tool is a 10MM ballnose tool that gives a theroetical roughness 0.006MM if you change the roughness to 0.01MM and you are switching back to step size you should have the result from roughness and tool.

The import/export from tool librariers should support also ASCII files.

All that should work with UNDO/REDO and with a fast display performance if you have a lot of calculated tool path on the screen.

The CAD/CAM dinosaur

Rank: 1

Dan

Newbie

posts: 0

Registered: 2002-8-26

Message 3 of 11

30-07-2004 08:56 . am   |   View his/her posts only
>> If you change the step type the step value should also calculated to the right value.

Why don't you write a PCR about this??? Sounds like a very reasonable request.

Another problem is how do you fill using genuine property sheets instead of traditional multi-tabbed dialog boxes as parameters?

Property sheets (PS) have the advantage of being more natural in a tree so you can collapse Setup1.ToolPath1.Limiting.Z and Min and Max are there in the tree with an edit field. This gives ultimate understanding and enables us to give full QM engine dynamic interfaces. Traditional multi-tabbed approach is very static plus the layout information is pretty rigid and the tradeoff keeping the viewing area as much as possible can make the parameter list a bit too long. PS doesn't require extra dialog boxes and are expanded in the tree.

I know are guys they love dialog boxes but for example if I want to reuse Setup1.ToolPath1.Limiting.Z parameters to Setup1.ToolPath2.Limiting.Z you cant simple do natural cut and paste operations. Now I will append two screen captures of property sheets to give you an extrahint about what Im talking about.

Rank: 1

OldForumPost

Newbie

posts: 0

Registered: 2012-1-14

Message 4 of 11

30-07-2004 09:08 . am   |   View his/her posts only
We have send for all things from my wishlist PCRS, excluding the operation bundle for transforming. But I will do it know.

The CAD/CAM dinosaur

Rank: 1

ChrisWard2k2

Newbie

posts: 2

Registered: 2011-11-22

Message 5 of 11

03-08-2004 03:48 . pm   |   View his/her posts only
Certainly, I agree that a dynamic, flexible interface should be our "holy grail". There is no reason why the "set up view" should not temporarily take the whole screen for User inputs. Far better to have acess to everything you need "up front", than hidden by tabs - especially true when you forget to set an essential option for your task (because it is hidden in the depths of tabs), and end up waiting 10 minutes for a toolpath calc that therefore is not going to be correct.

The Microsoft property sheet in example image PS2.gif (Internet Explorer properties) is pretty User Friendly with descriptive prompts. However, image PS1.gif (Post Processor properties) is definetly too "geeky" in terms of an example of a good CAM interface. A really effective post processor has to have a level of geek content (but could be made more User Friendly with well-written hints) because of the nature of CNC code. The CAM interface must avoid this geeky, buzz-word trait and be User friendly with icons and hints that clearly describe what each option is for.

So the basic proposal is to have property sheets for each toolpath, such that a PS could be copied and pasted, then edited so that all common options may be retained without the User having to re-select them. That sounds really great. I would like this to be a manufacturing plan rather than just the CNC plan. There are often occasions when the work piece is removed from the machine, under goes another process, then gets returned to the machine - or indeed a different machine. Each Object in the CAM tree can be dragged (or cut & paste) to reorganise the tree so that it always displays the chronological order of events.

Rank: 1

Dan

Newbie

posts: 0

Registered: 2002-8-26

Message 6 of 11

04-08-2004 11:18 . pm   |   View his/her posts only
So Chris you'll like (like me ) to have property sheets instead of tabs in a static dialog box? This is my opinion too should be an uniform cascading tree that gives easy cut and paste at various levels. Plus property sheets doesn't require X,Y layout information that will make dynamic plugins of new engines difficult.

The post image is there for the widget looking example and is a dynamic generated tree based on a XML file. Treat it as an widget not as an post! The widget itself has a status area for online hints so isn't too spartan!

Great I'm still waiting for more opinions. If will be to improve something your feedback guys is highly appreciate!

Rank: 1

ChrisWard2k2

Newbie

posts: 2

Registered: 2011-11-22

Message 7 of 11

05-08-2004 10:45 . pm   |   View his/her posts only
Yes, I prefer to see the tabs go, there are simply too many of them. This is because everything is squeezed into a narrow form. I would also like to see the Solid Verification integrated into the same graphics window, rather than the upheaval of "loading" a seperate environment. A better CAM interface will make life easier and increase productivity. As I mentioned before, it should be a manufacturing plan, not just a CNC plan - include User-definable PS objects for other processes, so that the tree truely reflects the history of the job. However, priority still needs to be bug fixes and solutions for current limitations.

Rank: 1

OldForumPost

Newbie

posts: 0

Registered: 2012-1-14

Message 8 of 11

06-08-2004 04:38 . am   |   View his/her posts only
If you thinking and planning a enhanced CAM GUI please think also about the tool path documentation. The most other ones have a HTML based page that shows the part, the tool path, and all important tool path informations (XYZ space, tool, step, surface offset, etc.) I have seen the HTML tool path documentation from CATIA V5. That people have made a nice thing. If you have your HTML page you can change inside that page step size or tool, etc. after a SAVE from the HTML page CATIA V5 starts and recalculate the tool path. That is the perfect thing for lazy persons like me


The CAD/CAM dinosaur

Rank: 1

Dan

Newbie

posts: 0

Registered: 2002-8-26

Message 9 of 11

06-08-2004 08:24 . am   |   View his/her posts only
(this is reply to ChrisW)

This was my initial design 2 years ago ech tab to be direct in the tree and all modifiers cascading in the tree. I fill it way more natural to use and much more easy to code mantain and implemet dynamic browsers.

Rank: 1

Dan

Newbie

posts: 0

Registered: 2002-8-26

Message 10 of 11

06-08-2004 08:31 . am   |   View his/her posts only
Dear Thomas,

If we are planning to change and what would be change is still a bit unclear.

But are chances this things to happen and my dream is like yours to have one of the most advanced product in market. QM already uses XML everywhere that is rendered to HTML via XSLT layer and its dump has links to cache entries that if you have proper development tools (like me ) can give you very quick information about various stages in toolpath generation. I use them extensively to figure out what is wrong.

Of course if we will do it be sure all the small things will be there including professional reporting, full update of the tree based on dependencies, etc, etc.

Rank: 1

ChrisWard2k2

Newbie

posts: 2

Registered: 2011-11-22

Message 11 of 11

06-08-2004 03:53 . pm   |   View his/her posts only
Can you get hold of a screenshot to give us a better idea of the HTML page as the User sees it? I have used programs with HTML front-ends, they look nice but it does not have to be HTML to look nice.
See also
X