CamBam plus V1.0 (rc-1)

[10bulls]

Don't know whether it has been upgraded in the newer releases (current is 6.4.0) but after 5.12.0 the main menus in CB became very ugly so I rolled back.

Hi Andy, nice to hear you, for the fonts on Linux, I have found that some interface font could be changed (at least in 0.9. and reassigned, but some don't.

How about a global setting for the interface font size.

Turns out, default system fonts and sizes are hard coded into the mono libraries.
'Tahoma' size 8.25 for older versions and 'MS Sans Serif' size 11 for later versions.
Adding a config setting for this seems the best option.

Speaking of mono updates breaking things, I noticed some toolbar icons have their transparent backgrounds broken in latest 6.4 libmono.
This is now fixed and will be in next update.

   

[Bob La Londe]

Andy,
I read about improvements regarding the output folder but it seems nothing major has changed.
Still, IMHO, a common output folder for all machining files included in the CB Options will be quite useful.
If the line is not empty and refers to an existing folder - use it as a common place for .nc file generation. If left empty - apply the other output methods.
Or maybe instead of a separate option at least CB could remember the last .nc file output folder so that next code generation will point right there.
In my work practice I generate all files in a dedicated folder and then they are copied over the internal network to the Mach3 PC. Currently I have to manually select it each time. I don't keep old .nc files but rather generate new. In this way the project folder is kept more clean only with geometry and .cb files in it.

Also, how about preventing layer automatic expansion? Or placing layers and Machining on separate dockers?

I'll have to experiment and see what happens, but I absolutely would NOT want all output files itn eh same directory.  It would destroy my work flow and confuse my work.  I would really like output file to remain constant for each project file.  

My typical directory structure is like this.

/Customer Molds/JohnSmith/4inWorm/CODE/Left 6x 3y p75z TL00.nc

Forcing every output to the same folder would destroy thousands of hours of work as the file name "Left 6x 3y p75z TL00.nc" exists in dozens if not hundred of customer project folders.  

As it is even the persistent folder that occurs now has destroyed my work more than once.  I always have to remember to look up at directory bar and make sure its saving the code file in the correct directory.  

If it remembered the output that was last used for THAT project file then the risk of over writing other work would be much less.  

In addition, I would like to do away with automatically writing a code file if the last used code file does not exist.  It should always ask.  One extra click would reduce or eliminate the lost files that sometimes occur the way it is now.  (or was in the 1-16)

[Bubba]

In addition, I would like to do away with automatically writing a code file if the last used code file does not exist.  It should always ask.
*********************
+1

[ThisAmplifierIsLoud]

+1 !

[Dragonfly]

/Customer Molds/JohnSmith/4inWorm/CODE/Left 6x 3y p75z TL00.nc

Forcing every output to the same folder would destroy thousands of hours of work as the file name "Left 6x 3y p75z TL00.nc" exists in dozens if not hundred of customer project folders. 

If the CamBam files are in '/Customer Molds/JohnSmith/4inWorm/' then you also have to select manually the 'CODE' subfolder.
You can also have the same structure in the fixed folder. In my case it's called 'MOP' and is in the root of the disk partition. Easier to locate. And shared explicitly on the network.
It's a matter of personal preferences and settled work pattern really. I am just asking, shouldn't I?

And while my proposal on this is questionable I think most will agree that the current visual interface with auto-expanding layers and machining pane below them makes it harder to keep track what one does, especially with 5+ layers and 10 or more parts with many MOPs in them.

[EddyCurrent]

It's nice to see an update, but for the next one I would like to see some of the existing plugins rewritten 'correctly' and incorporated into the standard CamBam build. As previously mentioned 64bit looks like a necessity.

[Mark81]

It's nice to see an update, but for the next one I would like to see some of the existing plugins rewritten 'correctly' and incorporated into the standard CamBam build. As previously mentioned 64bit looks like a necessity.

I fully agree with you, Andy. And I quoted your whole post
Perhaps it's not too late to include them in this one?

The last "update" (technically from alpha to rc) took 442 days.
The last real update (0.98P) was 1465 days ago and we don't know when the 1.0 will be officially released...

As I said several times, I would be happy to pay my licence again if this might speed up the development.

[Bubba]

It's nice to see an update, but for the next one I would like to see some of the existing plugins rewritten 'correctly' and incorporated into the standard CamBam build. As previously mentioned 64bit looks like a necessity.

+1, Again

[Bob La Londe]

As I said several times, I would be happy to pay my licence again if this might speed up the development.

I actually bought a second license to show support. 

[10bulls]

As I said several times, I would be happy to pay my licence again if this might speed up the development.

I actually bought a second license to show support. 

Yes you did, you wonderful mad lad, and very appreciated too! 

But please don't let this set a precedent. 

I have always been reluctant to keep charging for 'upgrades' each year or so.  Mostly as the core aim of developing CamBam was to help empower and encourage people to make wonderful things with CNC (in this CamBam has been a huge success and I am continually humbled and proud to learn what CB gets up to!).

There are still many improvements planned and requested for CamBam and to do this sustainably, it is nearing the point where a new paid upgrade is planned at some point.  However, this would only be offered if it offers considerable extra features / performance than the current version.  But more on this later.

First, lets bang those last few nails in 0.9.8's coffin lid and get V1.0 ship shape and doing real work!

Another great way you can support CamBam, if you are happy working with it, is to spread the word.
I know a lot of you already do this, so a huge THANK YOU!

[lloydsp]

Andy, I know I have done, but I think pretty-much everyone here actively promotes CamBam as being the best 'bang for the buck' in the CAM world.

Another thing:  Andy, you have no idea how wonderful it is to see you back and participating here again.  We always knew you were 'out there', but having you here among us again is good!

Lloyd

[Bob La Londe]

As some of you know I make a few videos when I feel inspired to on YouTube.  Sometimes I'll make a part and video the process only to have the only response in the YouTube comments be, "Please make more CamBam videos." 

David certainly makes the best visual CamBam tutorial videos, but I have made a few in response to other users issues from here on the forums.  Often those are my most viewed videos. 

[Bob La Londe]

/Customer Molds/JohnSmith/4inWorm/CODE/Left 6x 3y p75z TL00.nc

Forcing every output to the same folder would destroy thousands of hours of work as the file name "Left 6x 3y p75z TL00.nc" exists in dozens if not hundred of customer project folders.  

If the CamBam files are in '/Customer Molds/JohnSmith/4inWorm/' then you also have to select manually the 'CODE' subfolder.
You can also have the same structure in the fixed folder. In my case it's called 'MOP' and is in the root of the disk partition. Easier to locate. And shared explicitly on the network.
It's a matter of personal preferences and settled work pattern really. I am just asking, shouldn't I?

And while my proposal on this is questionable I think most will agree that the current visual interface with auto-expanding layers and machining pane below them makes it harder to keep track what one does, especially with 5+ layers and 10 or more parts with many MOPs in them.

I have favored and not been the only one to suggest that we have the option to be able to split the tree panes apart.  

As to not asking.  You can certainly ask.  I just wanted to make the point; to my own benefit of course; that everybody's work flow is a little different, and that it might need to be more flexible than you suggest to accommodate more users.  

[Dragonfly]

.... Mostly as the core aim of developing CamBam was to help empower and encourage people to make wonderful things with CNC (in this CamBam has been a huge success and I am continually humbled and proud to learn what CB gets up to!).

Not a grain of doubt about that, Andy! I think the success is due to the idea to provide a set of fundamental machine ops and leave the rest to the imagination and creativity of the user. It encourages brain work and is great in that respect.
After using it for a reasonably long time I still find new things and work approaches.

... I just wanted to make the point; to my own benefit of course; that everybody's work flow is a little different, and that it might need to be more flexible than you suggest to accommodate more users. 

Yeah Bob, everyone would like to see CB tailored to his workflow Let's leave the decision to the author.

[onekk]

IN my opinion, the best that could be done for CamBam:

1) is ironing out the bugs emerged in time.
2) integrate the most used plugins (I think the num move plugin, and maybe the zoom plugin and the view plugin (I'm not remembering the names))
3) add some CAD features, like the estend the line boundaries to another entity, or put some circles on a pointlist (I have this code in one on my WIP plugins) it is useful to mark some point and then drill them using the circle generated using the point on poitlist as the center.

4) maybe some console input like LINE(10,10) (10,20) to make a line and so on, it will speed up the make of things by scratch

5) complete API documentation

6) A way to extend the entities this would facilitate the work on those that write complex plugins, for now we have to tweak the things using the "TAG" attribute, some custom atributes added to entities maybe adding an XML property that could access and extend the XML structure of the .cb file.


Regards

Carlo D.