@conn.lee wrote:
Thanks, I've done some digging:
https://stackoverflow.com/questions/23778814/tape-drive-directory-path-on-windows-8-1
"Most likely you'll want to enumerate the attached devices using
SetupDiGetClassDevs()passingGUID_DEVINTERFACE_TAPEas the class GUID, followed bySetupDiEnumDeviceInterfaces(), then you can get the device path usingSetupDiGetDeviceInterfaceDetail(). You can then open it usingCreateFile(). "
Looks like I need to use Setupapi.
h to setup the API first, would it be just like a call class function? looks like I need to include the .lib import library, any pointers much appreciated.
No you don't. LaVIEW can do nothing with a lib file. You basically would have to configure half a dozen Call Library Nodes by hand to call those setupapi functions and some of them are just as nasty as the DeviceIOCtrl() call. If you really want to go down this path you are in for a very in depth learning curve about low level C programming details and how a C compiler normally aligns data in memory. This is about one magnitude more complicated than writing all that code in C since there you don't worry about memory alignment of data explicitly and the compiler takes care of that.
@conn.lee wrote:
Thanks RalfK, a much needed reality check, USB tape drive is much trickier than I expected.
My task is to do File I/O processing to tape, I tried using National Instrument's VISA, that seemed to have located the tape drive and made the connection to the tape drive. Fingers crossed!
That's even worse. People think that USB is a single interface but it is not. It is like the Ethernet connection, just the physical transfer but the actual protocol layers used like IP, UDP/TCP, FTP, HTTP, HTTPS etc are all very different and need to be understood and adhered too as well. Same about USB. You have more than 2 dozen different device class profiles for USB devices and all implement their own low level endpoint specifications and datastream formats. You would have to implement them all in LabVIEW and without a very detailed low level specification of those formats it is simply impossible to do and even with such specifications a total pita to implement.
VISA only supports USB-COMM (the virtual serial port specification), USB-TMC (a device specification that behaves like a GPIB instrument but over USB) and USB-RAW (The lowest level USB specification on which all the device class specifications are implemented on). You can theoretically talk with most devices if you implement the according device class implemention on top of USB-RAW but it ain't be pretty to do that.
Basically your task to read that data without the backup application that was used to write it to is pretty much doomed. If you are lucky that application used the Windows Backup API as you showed in one of your links and you can read it back with that API, but it's going to be pretty difficult to do since the documentation of that Backup API can be at best called sparse.
But that API was introduced by Microsoft around Windows XP and your old backup application might be older and use its own proprietary stream format to store the data to the tape. You would have first to find out what backup application that was and what format it used (first is probably easy to do, second might be impossible to find out as that is not considered useful information for users). Basically restoring backup data from a tape or similar device with anythhing but the original backup application was never really possible.
Well, if it is 20 years old it definitely predates the Windows Backup API. That means that the DLL in question most likely either interfaces to the ASPI (Adaptec Advanced SCSI Programming Interface) driver (it would then link to the wnaspi32.dll) or through the Windows device interface with SCSI passthrough IO Control blocks.
The first doesn't work on Windows systems after XP and the second is a pretty sparsely documented functionality that always required at least some Windows device driver development kit header files to get it to even compile. The first also won't support devices with USB interface for sure, the second could theoretically be made to work with the USB device with most likely just minor modifications to the lvSCSI.dll. But without source code for that DLL this is going to be a major pitta.
Depending if the lvSCSI.dll only provides the actual SCSI API or also implements some actual tape related stream management it may be basically almost impossible to read back the data without the source code to this DLL. If all the stream management was located in the LabVIEW VI's (very unlikely if your readTape.vi and writeTape.vi are mostly just very few Call Library Nodes into the DLL) then it's theoretically possible although you still would have to come up with a lvSCSI.dll replacement somehow, otherwise it really looks dire. If you want you can send me the DLL and VIs for a short analysis.
There used to be a (Australian) alliance member (Icon Technologies I think) who sold a SCSI Toolkit for LabVIEW. Your lvSCSI.dll might be from that Toolkit. It doesn't seem like they are still offering that Toolkit and the current people there might not know anything about it anymore.
Hi lee,
no, I don't talk about this specific tool.
I just used Google to search for "HP tape drive USB" and came to a page, that mentioned software from HP.
When even the tools from HP don't recognize that drive then either you use the wrong software tools or didn't install all needed drivers!
