stripped down CN for testing?

Discuss Thermwood 3-axis Machinery, Controller, and Software.

Moderators: Jason Susnjara, Larry Epplin, Clint Buechlein, Jim Bullis

Post Reply
Mark Hesketh
Guru Member
Posts: 366
Joined: Fri, Aug 25 2006, 9:12AM
Company Name: Paris Kitchens
Country: CANADA
Location: Paris, ontario

stripped down CN for testing?

Post by Mark Hesketh »

Just wondering what the possiblity would be for getting a stripped down version of CN to load on my programming computer for testing purposes. What I mean is, we generally load multiple jobs at the same time into CN and nest them together for cutting. Depending on the jobs, this can have quite an effect on the total number of sheets of material we need. Another thing we do is nest about 10-15 jobs together at one time and turn off all of the parts except for parts with veneer sides to them. That way I can load and cut all the finished parts for a few days at one time, getting them to the finishing room ahead of the white mel parts, and greatly reducing the number of loads of material I have to move with the forklift in our limited space, and how many offcuts I have to juggle. What I would like to be able to do is have a stripped down version of CN on my programming computer so that I could load the batch that I want to run a day or 2 in advance simply to nest them together and get an accurate sheet count. This way I can warn our ordering guy if I am about to use up all our stock of a certain material, also to let him know exactly how many sheets I need of the more expensive specialty materials we often run into. Doing this at the machine is not possible due to the time it would take away from cutting jobs. (we have 2 machines, and I am working serious overtime every week keeping them cutting as much as possible, just to try and keep up with the schedule.) This stripped down version wouldn't need to actually be capable of writing the nc code, just be able to be set up with the same settings as our machines and nest multiple jobs.

Sorry for the rambling on... it's too early on a friday of a week that has been too long.
Forrest Chapman
eCabinets Beta Tester
Posts: 1236
Joined: Mon, May 30 2005, 2:26PM
Location: Anderson SC.
Contact:

Post by Forrest Chapman »

Mark,

I've been requesting something like this for a while now. Hopefully they will come up with an answer to our dilema. As an extention it would be nice to create a file from there that the machine can write code directly from.

Forrest
Mark Hesketh
Guru Member
Posts: 366
Joined: Fri, Aug 25 2006, 9:12AM
Company Name: Paris Kitchens
Country: CANADA
Location: Paris, ontario

Post by Mark Hesketh »

I was thinking about including a request to be able to write the code at the computer and send it to the machine from there... but then I realized that there would be all sorts of problems for any place that has multiple machines. We have 2 machines with slightly different setups (ie, one has a drill bank, one does not, the one without has extra tool holders, etc.) and I know that we cannot share code writen at one machine with the other.

So, unless it were to become even more sophisticated to be able to choose between multiple setups, I figured I would just stick to asking for something much more basic.

But as for what you were mentioning Forest, I don't imagine it would be too difficult to create a CN for the computer that would create the code for a single machine setup... the programmers can correct me if I am wrong, but you should be able to, more or less, just take the CN software and tweek it a bit for this to work, or strip certain functions out to simplify things.

Just making sure the programmers never feel that they are running out of things to do :wink:
Forrest Chapman
eCabinets Beta Tester
Posts: 1236
Joined: Mon, May 30 2005, 2:26PM
Location: Anderson SC.
Contact:

Post by Forrest Chapman »

Mark,

The problem with writing code from your computer is there is nothing unique about the code so it can be run on most any brand machine. This obviously doesn't fall within the scope of Thermwoods vision. However there would be a way to use the parameters stored in the Control nesting system if the machine was networked. All you need is a link to each router.

Something much more simple for now would be the ability to add multiple jobs in ecabs.

Forrest
Mark Hesketh
Guru Member
Posts: 366
Joined: Fri, Aug 25 2006, 9:12AM
Company Name: Paris Kitchens
Country: CANADA
Location: Paris, ontario

Post by Mark Hesketh »

I am deffinately looking forward to the day when I can network the multiple machines together... that way I can share offcuts much easier.

If ecabs could be made to load multiple jobs, that would solve what I am looking for... I hope. Though I have noticed a few differences between nests done in ecabs and those in CN. I would worry about how much this would slow down ecabs. I already have some larger single jobs that take a few minutes to load in ecabs, and 5-10 minutes to nest. What would happen if it were to have to handle multiple jobs? That alone is the reason why I was looking for a stripped down version of CN instead of an add-on for ecabs.
Ryan Hochgesang

Post by Ryan Hochgesang »

Hi All,

We currently do not have any plans on implementing the suggested \"stripped down\" version of software at this point, however, we will certainly take this idea into consideration.
Forrest Chapman
eCabinets Beta Tester
Posts: 1236
Joined: Mon, May 30 2005, 2:26PM
Location: Anderson SC.
Contact:

Post by Forrest Chapman »

Mark,

When you nest a large multi job how long does it take to write the code. Someone here was having issues with long processing times and now I'm getting the same thing. This job is all the same material and was almost 100 sheets. There were more than 1000 parts of the same material so I had to cut out some of the rooms to get it to nest however it is still taking more than 30 minutes to nest and has been over an hour writing the code. I had this problem many moons ago but David Hall suggested that I clean up the harddrive and that seemed to take care of it. I guess I'll try that again although I checked a week ago and it was fine.

Forrest
Mark Hesketh
Guru Member
Posts: 366
Joined: Fri, Aug 25 2006, 9:12AM
Company Name: Paris Kitchens
Country: CANADA
Location: Paris, ontario

Post by Mark Hesketh »

Hey Forrest
I had a similar problem long ago, and cleaning up the harddrive fixed it that time. Lately I have been having serious issues with nesting times, just like a few others. Some have been so bad that the program actually shows as \"Not Responding\" in the program manager and I have given up and killed the program after a half hour or so of waiting... I just don't have time to be overly patient.
I just ran a job last week that was somewhere just under 1000 parts with 3 materials, 3/4 mel, 1/2 mel for backs, and 5/8 mel for shelves and metabox drawer parts. I turned off everything except for the 3/4 parts, which is still the majority of the job, probably around 700 parts. nesting this didn't take too long, but writing the code took about half an hour. I don't remember my large jobs ever taking this long before.
Lately, any time there are ANY dovetail drawers included in the programs, even if I turn them off and only nest other material, it really slows down the nesting. I also occasionally come across seemingly random combinations of jobs that if I nest them together cause problems. don't know why, and haven't figured out how to get around it. I've just been trying to be patient and wait when it bogs down... and have even given up and run smaller batches a couple of times.
DanEpps
Wizard Member
Posts: 5852
Joined: Thu, Jul 28 2005, 10:18AM
Company Name: Dan Epps
Country: UNITED STATES
Location: Rocky Face GA

Re:

Post by DanEpps »

Mark Hesketh wrote:...the program actually shows as "Not Responding" in the program manager and I have given up and killed the program after a half hour or so of waiting...
Just as an FYI, "Not Responding" is a little misleading...it simply means that the program is not currently "talking" to the operating system, not that it is not running. This happens quite often in long processing situations. What happens is that the procedure reports to the operating system only when it completes successfully or fails and does not communicate progress. Maintaining progress updates to the operating system can cause the procedure to take much longer (and in some cases is impossible) so programmers normally don't communicate progress in these situations.
Jeremy Schiffer
eCabinets Beta Tester
Posts: 1119
Joined: Tue, May 10 2005, 9:36PM
Company Name: Corlane Custom Cabinetry LLC
Country: UNITED STATES
Location: Carnesville, GA
Contact:

Post by Jeremy Schiffer »

I think the best compromise here would be to be able to load multiple jobs into eCabs. The job Forrest is referring to was for me, and I had it broken into about 10 or 12 different \"rooms\" so as not to slow the computer down too much while designing. But at the end, I would love to be able to re-combine those jobs and nest them all at one time. I couldn't order the plywood for the toekicks because each separate job probably used two or three sheets of plywood with lots left over. Had I nested each one individually and added the totals together I would have probably ordered at least a dozen sheets of plywood over what was actually needed. Fortunately Forrest took care of the plywood for me.

So for those of us that don't have a router, or who outsource jobs to a Production Sharing shop, it'd be nice to be able to combine jobs together in eCabs so that we'd know how much material to have shipped to the shop.
http://www.corlanecabinetry.com

Intel Core i7-5820 3.3GHz, 16GB RAM, NVidia Quadro K2200 4GB, Windows 8.1 Pro 64 bit
CS-41 4x8
CS-45 5x12
Greg Cannon
New Member
Posts: 11
Joined: Sat, Apr 07 2007, 10:07PM
Location: Upland, CA 91786
Contact:

Post by Greg Cannon »

I agree with Jeremy. I have been a Software Engineer for the better part of 25 years and am starting up a production sharing business so I will have a Plan 'B' when get tired of competing with college kids for programming jobs.

I recently ran into an issue with Control Nesting and it's interpretaion of metric DXF files. After much ado, Thermwood released a CN patch, but in the interim I went through most the software processes, looking for a better way.

I have had a few DXF jobs that would take an extended period of time (several hours) to process, only to end up with \"a common close point could not be found'. Since the DXF rendering can only be done in CN, I cannot cut any other jobs until this process completes. Bummer dude!

If all nesting, rendering and DXF processing happened on the desktop via eCabinets or another offline application, and that application produced a TWD file, and the SuperControl could simply process TWD files, everyone would win.

It could deal with DXF files offline, the Imperial to Metric conversion would take place before the SuperControl got involved and, most importantly for Thermwood, the file produced would still be Thermwood specific, thus preserving the market for the machine.

Let the CNC machine focus on cutting and move the managerment operations to the desktop.

I could then push pre-processed TWD files to the machine, via network or sneaker-net (USB, floppy, etc) and keep the machine earning its keep.
Mark Hesketh
Guru Member
Posts: 366
Joined: Fri, Aug 25 2006, 9:12AM
Company Name: Paris Kitchens
Country: CANADA
Location: Paris, ontario

Post by Mark Hesketh »

Hey Greg, for something like that (which could be quite useful) I think there would have to be some sort of network connection and communication between the supercontrol and the desktop so that the desktop is updated with tool sizes and other settings. I would love to be able to share offcuts between our 2 machines, but because there is no current network communication for the supercontrols, it's not possible. Maybe something like sepperating some of the functions from the supercontrol could be implemented in the future when a networking version is worked on.

did any of that make sense?
Greg Cannon
New Member
Posts: 11
Joined: Sat, Apr 07 2007, 10:07PM
Location: Upland, CA 91786
Contact:

Post by Greg Cannon »

There are 2 seperate issues here:
1) The offiline processing of DXF files and
2) The transfer of offcut info from one machine to another

Regarding #1, eCabinets can manipulate drawings and generate TWD files independantly from the SuperControl and w/o any knowledge of the tools and machine capabilities. All I am asking for, in simple terms, is a DXF-to-TWD converter. Once the TWD is imported to the SuperControl, then the tools would be applied and the nesting would be done. Using this concept, there is no need for any ongoing communications with the controller.

Regarding #2, it appears that offcuts are stored in a Microsoft Access file as an array of vertices, or corner points, along with linking info about the material (thickness, grain, etc). Entering or scanning the barcode number simply looks up the corresponding record and imports the vertices insted of you manually typing each corner x,y value in manually when you add a sheet.

It would be relatively simple to write a utility to export the data from the MDB file to XML. The toughest part would be handling duplicate barcode numbers, since the machines generate these unique IDs independantly. This could be handled by presenting the user with a dropdown list or other GUI that allows you to select the desired sheet.

Physically networking these machines is fairly easy. They run standard Windows XP and have Ethernet ports built in. But even w/o a network, data could be carried between machines via a USB drive.

I am mostly interested in#1, but #2 is much more easily solved.
Post Reply