ShaunR

Is THIS the sort of thing you are after?

Is the issue here that you are trying to do a two stage process in 1 go? i.e read from a Solaris drive, process the data and save it to NTFS? The 25MB/s might just be the limitation of the solaris drive (ATA 33 perchance?) and you might not be able to overcome that. What about slapping a brand new 1TB NTFS formatted SATAII drive (they are cheap after all) in the windows box alongside the UFS drive. Start a flavour of linux (such as Debian) in a virtual machine or as a live CD. Install this Linux-NTFS in the virtual machine or live CD and just copy everything to the new drive. Throw away the old drive or take it home to build you own solaris system Then run your software on the data, NTFS to NTFS. Probably missing something as per usual

Is the unit addressable? You may be seeing the units address prepended. The manual will tell you more.

Indeed. Nebulus describes a "hardware abstraction layer"But you can also have "software abstraction layers" for example ADO for databases.

Not being aware of the info-labview discussion-heres my two penneth. In general terms. An abstraction layer is an interface presented to higher level funtions, that hides the implementation. In terms of Labview, a good example of a HAL (hardware abstraction layer) would be VISA.

Thinking laterally (or is it vertically). You could create a single global event that each control can decide to register with or not. You can then filter the incoming events and take decisions based on either its type (boolen, numeric cluster etc) or a specific control. What this acheives is that changes to the system are consolodated into 1 vi.

Heathen

Yep. That would do it. The key point being "ActiveX". You can try to make sure the open ref is only executed once (when the vi is started...ie outside any loops) and hope that the "stall" isn't from the get method.

Check to make sure you have "wired through" the shift register. You will normally see this behaviour if there is a case selector with an unwired tunnel. If there is a case which has no wire connecting the left shift register node to the right node, that case will insert a "NULL" reference.

It can be done (including your additional criteria) by saving the vi as a template (vit). You can then open it in edit mode (requirement for changing execution systems and priorities) modify the parms and then run it like this: However. This is probably not very helpful in the long term since the priority property is "Read Only" in the run-time engine so if you deploy it it will fail:frusty:

Private or public?

Does it currently auto-grow or do you have to make it grow manually?

You have to do a bit more than that to force LV to run certain vi's is certain threads. This is where "Threadconfig.vi" comes into its own. vi.lib\utility\sysinfo\threadconfig.vi It all gets a bit tricky from here on in as you need to manually manage what vi's are going into which execution systems and at what priorities. Most of what you need to know is in this thread (no pun intended...lol) Loop Timing & Execution difference

Didn't know Labview had a "Pizzle" . Amazing what the NI boys can do nowadays

I can't walk and chew gum at the same time either

There are examples shipped with Labview. Hardware Input and Output\General

Well. A sticky at the top would dramatically reduce the "Why Can't I" PMs. And although they may have something to put in the general area (although haven't seen many newbies that don't post relevent to their problems), it might be a worthwile excersise to lock it for a short period to "Train" them and ease the workload on the mods for moving them. Just my 2 cents.

+1 But how newbie does a newbie have to be? 10, 100, 500 posts?

Sorry Peeps. Couldn't post these in a PM so ignore me as I post them here for Cat. As Promised Cat.

Well. The Alpha thread (see what I did there ) doesn't discuss ideas, it preaches one persons view. I think we all have small minds before lunch when the blood sugar is low

Still none the wiser then...lol The correct translation is "Great minds discuss ideas ; Average minds discuss events ; Small minds discuss people."

Yes. There is a very easy way to do what you want. But not in the way you want to do it. Your array would be short right? (By short I'm thinking less than 2000 lines!) Just load all lines of the file using the "ReadLinesFromFile.vi" (-1 as the lines argument will read all lines regardless of file size) or "ReadFromSpreadsheetFile.vi" (the output of this vi is already an array type and also reads all lines regardless of size) to an array and let the user index through it. If you give him a back button (decrement) then he will also be able to go backwards (never say never...users are illogical creatures) with little effort on your part. Labview does this sort of thing much better than C/C++ since you don't have to declare array sizes before you start and arrays are self re-allocating so you don't have to manage the re-allocation (as you would have to in C). You also don't have to worry about overrunning the end of the array. GPFs are rare in LV Should take you 2 mins (including waiting for LV to load ) KISS!

I'm probably missing something huge here. But the beginning of an array is index(0) and the end is index(length-1). This is true if you add, delete or insert. The next item in the list is current index+1 and you just maintain an index to the current place in the list/array. No iteration, uses LV primitives but suffers from re-allocation penalties.

I'm not after anything, except a pay rise.lol

An array is a poor replacement for a linked list. A linked list is atomic and not contiguous in memory (hence the next-node pointer refs) and therefore doesn't suffer from memory re-allocation penalties when inserting, deleting or appending. You simply allocate the node and update the appropriate next-node pointer values. (The downside to this is of course fragmented memory). The main advantage of linked lists is that the operation time for insertion, append and deletion is consistent, which is not the case when array re-allocation occurs, since the re-allocation time is variable dependent on the array size. You can think of an array as a special (limited) case of a linked list where the list is of a fixed length and the pointer is the previous-node pointer+1. This case will perform the same as a linked list, but as soon as you insert, delete or append past the array length you will again get re-allocation penalties. I avoid linked lists like the plague in LV since I haven't come accross an effecient way of implementing them because the whole point of labview is that you don't have to worry about pointers . Perhaps a better way might be to write a dll (API) that manipulates your list. This may yield better results although you have other overheads but at least they will be consistent. Of course. this is only applicable if performance is the attractive quality of your linked list. If performance isn't an issue then just use a standard array and use the standard LV prototypes to insert, delete and append.