Feedback

[Anders Hellstrand]

Hi,

First let me say that you have written a good piece of software with great potential.

It's still some issues which is natural for an alpha release and I have only been using it for an hour but I'm sure it will be very useful now or in the very near future!

To contribute to the development I listed some issues and ideas with my rating of priority (p1 beeing most important)

Issues

- (p1) GCODE Style. Add a space between X and Y coordinates. 
Example: i.e G00 X1.6409Y-1.3200 >> G00 X1.6409 Y-1.3200).
Reason: Repetier host software, also open source and heavily used in home built machines, cannot parse the data otherwise.

- (p2) Labels of different hierarcical level (i.e in the Options tab) is currently separated by left/center alignment. It would be even more clear if the style would be different for thoose levels, i.e by having group level in bold or ~10% larger font and slightly more ”air” above the group label.

- (p3) In the ”Project” tab; the first item seems to be ”Title”- confusing where other items are objects. Proposal: Change style on labels or remove this one as it is not required label.

- (p3) Last used menu item are not selectable unless first hovering over another menu item. Reproduce for example by selecting ”Open gerber” (and open a file) and then open the ”File” menu again, hovering over item by item and observing the last used item (open gerber in this case) is not beeing highlighted properly.

Feature requests:

- (p2) Zoom and Pan in the preview screen with the mouse wheel (meanwhile showing zoom shortcuts as help text in the UI)

- (p2) Automate the "multiple isolation route paths" - it seems it works by manually doing it but a simple dropdown with number of passes would be convinient.

- (p4) Offset functionallity, i think it would be useful to have a shortcut to set offset for object to be placed in the positive space (left bottom object on 0;0) - perhaps this is not necessary and I should change the zero point on my CNC instead, let me think about it....

Keep up the good work,

BR/Anders

[Anders Hellstrand]

- (p2) Would be useful if the current directory is remembered between openings.

- (p5) Is there a reason to have "custom" file dialogs instead of OS native dialogs (i'm on Windows)? I miss the time stamps on files.

[jpcaram]

Thanks a lot for your feedback. This is great!

Some thoughts on your comments:

Gcode format: I believe I'm generating valid Gcode. Of course I want to help everyone, but just adding the space might break somebody else's program. Or maybe not, but I hope you see what I mean. Eventually I can add options to the file export so the users can adjust to their needs. Perhaps I can create some scripts to convert one gcode format to another. I'l keep this in mind.

Options tab: I'm working on that!

Project tab title: Agreed.

Menu items: I don't have control over that. That is built-in functionality in the GUI toolkit (GTK+3). It's such a minor thing!

Zoom/Pan: There is a bug in the GUI toolkit detecting the wheel. I'm looking for a workaround.

Multiple isolation paths: Yes, agreed!

Offset: I'm not sure what you mean here.

Current directory/File dialogs: The file dialogs and related behavior are part of the GTK+3 toolkit. They implement a custom dialog so the app can be ported between platforms without any changes. Otherwise I would need to do somwthing like if "in windows": Use this, else: Use that. I like the Windows file dialog better. Perhaps I'll implement that.

Thanks again!

JP

[Anders Hellstrand]

Hi,

I'm not sure if the standard(s!) states that that space should or should not be there or if it is optional. I fully agree that encourage others to follow standards are prefered and second best is another option in the UI. A simple solution would be to expose the formatstring you probably use, like "G00 X%1Y%2" making it easy to become compatible with next to no effort. I have used several firmwares on the CNC and they all had their small differences in what they accepted.... For now I use simple search and replace as workaround.

My take on the file dialogs is to not spend energy on thoose until the rest is stable but if you can persist folder between openings it would be great!

What I ment with offset is that for example kicad have 0,0 in the upper left corner giving the gcode getting negative values as axis are mirrored, where my cnc have 0,0 in the lower left corner... To tired to see what is right or wrong here with many tools in the toolpath. My idea was, instead of looking on the screen in flatcam for lowest X and lowest Y and apply thoose values as offset to do it with the click of a button. Another better way would be to set the offset correct in kicad to which i'm also new. Found two ways to set offset. Neither of them worked. Anyway not a showstopper. Focus on the drillparsing instead.

Thanks,
/Anders

[Hyrum Fairbanks]

I have some experience with CNC milling machines and several CAM applications used for creating tool paths. I plan on using your software to make some pcb's. I have a comment on the Gcode format.  

 

Of the handful of machines I have worked with, all had their own ver of Gcode as well as custom code needed to operate. Some need spaces, some need decimal points, and some have restrictions in how they are named or what the file extension is. Flipping the board over might be a manual process in one machine and an automatic one in another. It could be done on a rotary axis or with a custom fixture with a pneumatic toggle operated with a custom Mcode.

 

Like you said, it makes no sense to fix your software to work for a particular machine. All the software I have worked with includes the ability to use a post processor (sometimes just called "post"). This is usually just a setup that the user can edit if they need to. Once a post is made for a type of machine it can be saved and shared. I have a Haas which is the Chevy of CNC mills (good value machine very common in the US). If you made the ability to create a post I could make a post that would work on my Haas and would work or at least be a good starting point for any has machine.

 

Thanks,

Hyrum

[cuagn]

I don't know if it's in the roadmap, however I would point out a difficulty, for which an improvement is easy to implement

Not all bits are parallel (flat end). Basically, whatever the flutes quantity, we can find three models:

 

FLAT

BALL

CONE

For precise (depending on your machine) and tiny milling the cone seems to be the better.
The problem is that the diameter (isolation width for a single pass) is depending on  the depth and on the angle (30°, 45°, 60°, more...).
This can all be managed in a single window (tools) instead of using external computation (OK, that's not high mathematics).

From another gerber to gcode translator, it looks like

What do you thing about ?

Marc

[Juan Pablo Caram]

So, you are suggesting a calculator where you input ANGLE and DEPTH and it returns DIAMETER? That wouldn't be hard to implement. I will add it to the wish list.

In my experience though, the final diameter depends on your tool and how sharp it is, and your machine (how much it moves around the center... I'm sure there is a technical term for that), so if you want to cut a very thin trace, the diameter might end up much wider than the exact diameter at the given cutting depth. In other words, you know your diameter by experience.

JP

--
You received this message because you are subscribed to the Google Groups "flatcam" group.
To unsubscribe from this group and stop receiving emails from it, send an email to flatcam+u...@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[cuagn]

I fully agree that the diameter depends on the tool itself and also to the spindle motor and the quality of the collet.
Whatever the theoretical diameter, the result will be different. At least for amateur milling table.
This is true either for flat mill or for conical one.

My wish is not a "side" calculator (Excel is fine and easy), but an integration in a tool library with all parameters for each tool (as in the image of my previous post), including rotational speed [which is missing today (M03 starts the spindle but Sxxxxx is required to make it rotate, at least in LinuxCNC)]
As an idea, have a look to CopperCam (free without gcode generation : http://www.galaad.net/coppercam-eng.html). This may give a better understanding of what I mean.

Regards

Marc