Run a program off of USB

AF-METALS-TECH · Apr 3, 2008

Hello I was wondering if anyone can tell me if there is a way to run a program off of the USB port without saving to memory, the memory is not large enough to hold some of the 3d surfacing jobs. The machine is about two years old a VF1. Thanks for any help.

gar · Apr 3, 2008

AF-METALS-TECH:

I do not have a machine with USB. Thus, the following is general background.

I assume you mean to load a program on to a USB memory stick, then carry the memory to the CNC, and run the program from the memory stick.

What you want to do is DNC (drip feed). This should be discussed in your manual. There certainly should be a discussion of FLOPPY DNC and RS232 DNC. The only difference I would expect is how you route from the USB instead of the floppy.

The discussion on DNC is under Operation in the manual.

.

Matt@RFR · Apr 3, 2008

Insert thumb drive and hit the 'List Programs' button. Arrow down, arrow right. Arrow to select your program and 'select program' button. From here you can run graphics or run the program, but no editing.

I've run 5MB programs this way with no problems at all. Even at 300-400IPM feedrates, there's no stumbling.

t.lewis · Apr 4, 2008

It works but do not remove the drive during the running of the job.

gar · Apr 4, 2008

If you can not edit the selected program, then does that mean that it is effectively in DNC (drip mode)?

I assume that when you do this sequence of key strokes that you only see the list of programs on the memory stick. Are these displayed as O-numbers or as the DOS or Windows filename? If as a filename are you limited to the 8.3 form?

A test of whether this is a drip feed mode or the equivalent of the normal O-number list is whether you can call external subroutines, and where the subs are located. If external subs are possible, then are these limited to ones on the memory stick?

There is also the question of whether an O-number on the memory stick can be the same as in the normal O-number program list.

If this is effectively drip mode, then how much free memory is required in the normal O-number memory space?

.

Matt@RFR · Apr 4, 2008

I don't know Gar. I don't get nearly as involved in the electronics side of things as you do, and don't care to. It IS drip feeding, but Haas calls it FNC. What that means, I have no idea. And like said above, even after selecting the program on the USB, if you take it out, you no longer can run the program. It never enters memory.

I don't care how it works, as long as it works.

The real Leigh · Apr 4, 2008

Hi gar,

If you intend to run a program remotely, i.e. using the USB port to talk to a remote controller or program repository, there's a potential problem which must be evaluated: What does the machine do if communication with the remote is lost?

The consequences of this failure can run the gamut from innocuous to fatal. You need to investigate the error detection and recovery capabilities of the machine.

- Leigh

gar · Apr 4, 2008

Matt:

The reason for the question is that if the HAAS operating system program was not simply drip feeding, but was able to access external subroutines, it could be very useful. Also since the entire memory is on the stick in the machine there is no reason why internal subroutines should not be possible if the HAAS operating system was written appropriately.

In fact in a drip fed program you can not do jumps. Flow must go from one instruction to the next instruction.

Leigh:

I have to assume HAAS is treating the memory stick as a peripherial like a hard disk. If you were to use the USB as a port to another computer, rather than as hard disk, then whatever was serving as the driver for the USB at the computer end would have to make itself look like an interface to a hard disk. Not a real easy task.

A normal drip feed operation is a one-way street for information flow, other than for the start stop handshake signal. In drip feed it would be possible to do forward jumps, meaning further into the program, but I doubt HAAS allows this. Backward jumps would only be possible, and to a limited extent, if HAAS retained some of the CNC program after it was executed.

On the loss of communication problem it should be no different than standard drip feed thru the serial port. Here the machine just stops at the last received instruction and won't automatically restart.

.

Matt@RFR · Apr 4, 2008

You can run internal subs, but I don't know if external subs would work. I doubt it but am not sure.

gar · Apr 4, 2008

Mat:

That is certainly useful and makes the method better than RS232 drip feed.

.

AF-METALS-TECH · Apr 5, 2008

Thanks

Thanks for all of the info it is really hard to get an interface like a preditor too many hoops to jump through like geting the money, to have new software loaded , getting cables run to the machines and a whole lot more military burocracy. So I just went and baught my own 16 gig jump drive. I am going to try this out Monday.

Matt@RFR · Apr 5, 2008

16GB will hold a few programs!

It's super easy, just treat it the same way you do when you insert the thumb drive in your computer. Locate the directory (list programs), pick the file you want and run it.

HelicopterJohn · Apr 6, 2008

Program interruption

It seems that when I inquired about doing this the HAAS guy told me that if the program somehow got interrupted you had to start from the beginning and not a tool change.

Just something you might want to verify.

I didn't purchase the additional memory from HAAS but did like Matt and bought a 4 gig memory stick for about $30.00.

John

Donkey Hotey · Apr 6, 2008

I don't know how the machine could use subprograms: internal or external. It would have to load the whole remainder of the program into memory so it could read the subprograms at the end. Without that much memory, where would it get the info?

The drip feed is a serial feed. It's not random-access. It can't jump to the end to read it. Unless I'm totally mistaken.

The good news is that a file so large that it exceeds the memory of the control, implies that you sent it from a CAM program. If you have a CAM program, there's no need for subprograms. Just let the code flow out, in excruciated detail, without subs, and let it run on the machine.

Matt@RFR · Apr 6, 2008

HelicopterJohn said:
It seems that when I inquired about doing this the HAAS guy told me that if the program somehow got interrupted you had to start from the beginning and not a tool change.

John

I start at tool changes all the time from the USB, so I can say for a fact that it works. I do have my post setup so it outputs a safe line with each toolchange though.

Donkey Hotey said:
I don't know how the machine could use subprograms: internal or external. It would have to load the whole remainder of the program into memory so it could read the subprograms at the end. Without that much memory, where would it get the info?

The drip feed is a serial feed. It's not random-access. It can't jump to the end to read it. Unless I'm totally mistaken.

The good news is that a file so large that it exceeds the memory of the control, implies that you sent it from a CAM program. If you have a CAM program, there's no need for subprograms. Just let the code flow out, in excruciated detail, without subs, and let it run on the machine.

Hi Greg. Like I said before, I don't know how it works, but it does work. Once in awhile I want to probe several parts, so I hand write the code (which are external macro subroutines, as you know) and on top of that I sometimes have those macro subs called again in internal subs for use with several work offsets. All from a program running strictly off the USB thumbdrive.

Donkey Hotey · Apr 6, 2008

How big are the programs? I think the control reads what it can, until the memory is full. If you're doing testing with programs small enough to be cached in the control, I can see it working.

If the machine has 1 meg of memory and a 5 meg file on the USB, I still don't see how it could do it. Have you tried a file that exceeded the memory on your machine?

I'm not playing stump the dummy here.

I'm learning along with the rest of you.

Matt@RFR · Apr 6, 2008

Just ran a 3.6MB program from USB the other day, and have run much bigger too. And my machine has the stock (1MB?) amount of memory onboard.

Granted, I am usually using pretty small ball nose endmills (1/32" - 1/4") for my surfacing so the feedrates are fairly low, but I've seen no stuttering from memory starvation.

gar · Apr 6, 2008

With the information in the previous posts it now appears that the USB memory is not running in a drip feed mode, but is rather a random access memory from the USB memory.

The next question is one I think I expressed earlier. Is there a conflict if HAAS internal program memory has an O-number program with the same O-number as on the USB stick. If there is a conflict, then it might mean you could have an external subroutine in HAAS main memory called from a program running from USB memory. If there is no conflict, then it means all subroutrines, internal or external, have to reside on the USB stick.

.

The real Leigh · Apr 6, 2008

gar said:
With the information in the previous posts it now appears that the USB memory is not running in a drip feed mode, but is rather a random access memory from the USB memory.

Hi gar,

A USB memory stick should show up as a disk drive attached to the computer. That's the standard USB protocol implementation.

It would not look like a modem or other communication device. And it would not look like native RAM.

- Leigh

Donkey Hotey · Apr 6, 2008

The real Leigh said:
And it would not look like native RAM.

C'mon, keep up here.

We know how it's supposed to be addressed. The behavior described here suggests otherwise. It looks like the Haas Control is addressing it as Virtual Memory.

Run a program off of USB

Aluminum

Stainless

Titanium

Aluminum

Stainless

Titanium

Diamond

Stainless

Titanium

Stainless

Aluminum

Titanium

Cast Iron

Titanium

Titanium

Titanium

Titanium

Stainless

Diamond

Titanium

Similar threads