hi, everybody.
i want to program to input/output data in my device via usb.
how can i implement it in vb6?
can u help me?
regards
:wave:
Printable View
hi, everybody.
i want to program to input/output data in my device via usb.
how can i implement it in vb6?
can u help me?
regards
:wave:
don't believe anyone here can help with this, though i would be happy to be wrong about that
you need to contact the manufacturer of the device for appropriate sdk other api
Or do you mean to say you want to save and retrieve files from a USB drive?
Small World! I came to the forum today to ask exactly the question just posted by SGHSGM about interfacing VB6 to USB devices.
As far as I am aware, USB is very similar to RS232 except faster and an extra cable core supplies a limited amount of +5v power to an external USB device. In VB6 the MSCOMM feature provides an excellent 2-way interface to a RS-232 device, but you have to know (or write some code to work out) the COM port no. to which it is plugged. With a USB device, a COM port number is not generated - so MSCOMM could not work with it as is.
I believe that I have seen adaptor devices which plug into a RS-232 9-way and provide a USB connector.Maybe you would need separately to arrange the +5v supply to the USB device. If such adaptors work, it would seem that the USB device would appear as a detectable COM port, and then maybe MSCOMM could talk to it? A good starting point might be a device such as a Garmin GPS receiver head. These are available either as RS-232 or USB connectors, and they usually send data continuously without prompting. There may also be (faster?) usb converters which plug into a 25 way parallel port if you still have one of these. In all cases you would, as above advised, need the manufacturer's spec. as to message formats, parity etc. etc.
If you have a program or driver with the USB device, it may be possible to run that program through VB6 using appactivate and / or keystroke and thus to get data into or out of the VB6 program. But it would be so much better if there were an equivalent of MSCOMM for USB devices.
Increasingly external devices have the USB interface, so it is increasingly a significant shortcoming of VB6 that it does not have a USB interfacing routine / control available. I wonder if any later version of VB contains such a beast?
I will be very interested to see what other replies are submitted to this thread. Surely many VB6 users have asked just this question and tried to answer it?
camoore
Entirely incorrect, and this is where the confusion comes from. :down:Quote:
As far as I am aware, USB is very similar to RS232 except faster and an extra cable core supplies a limited amount of +5v power to an external USB device.
The important letter in USB is B, which stands for Bus, as in expansion bus. It is meant to be treated logically like the PCI, ISA, EISA, VESA, AGP, etc. slots... it just happens to use serial communication, and often to devices outside the PC cabinet.
Of course not. Why would you expect it to? Ah, hung up on the word Serial in USB are we?Quote:
With a USB device, a COM port number is not generated - so MSCOMM could not work with it as is.
Yep. Just like you can buy multi-COM cards to plug into an ISA or PCI slot.Quote:
I believe that I have seen adaptor devices which plug into a RS-232 9-way and provide a USB connector.
There are no later versions of VB, unless you mean VB.Net which is really something else altgether. And no, you aren't any better off with VB.Net, C#, C, C++, Java, or moonbeams.Quote:
Increasingly external devices have the USB interface, so it is increasingly a significant shortcoming of VB6 that it does not have a USB interfacing routine / control available. I wonder if any later version of VB contains such a beast?
So stop blaming VB6 for this. :duck:
We sure see this same question a lot.
How come nobody ever asks for MSComm to talk to their SATA or Firewire ports I wonder? :confused:
I have added to my program a file backup and restore from a usb flash drive and there are many considerations eg: more than 1 flash plugged in, no flash plugged in, not enough room on flash etc. This may give an idea. I am making a portable version of my software where the flash drive has to be purchased from me. To do this it has to be a U3 flash drive that also contains a cd drive letter
with a burnt in iso imag. The hardest part was replacing the burnt iso image with mine. When the usb is plugged in it looks for my iso and will not run my software if not found. Hope this code helps:
'Loop thru the drives and find removables
Code:Public Function GetUsbDriveLetter(usbFolderName As String) As String
Dim UsbDriverLetters() As String
Dim DriveLetterToUse As String
Dim Counter As Integer
Dim i As Integer
Dim UsbDriveLetter As String
Dim TmpDriveLetter As String
Dim CdFlashDriveLetter As String
Dim freespace As Double
Dim MostSpace As Double
30 On Error GoTo e
40 Counter = 0
50 For i = 65 To 90
60 If DriveType(Chr$(i)) = "removeable" Then
70 If Chr$(i) <> "A" Then 'A shows as removal also
Counter = Counter + 1
80 TmpDriveLetter = Chr$(i)
90 ReDim Preserve UsbDriverLetters(Counter + 1)
UsbDriverLetters(Counter) = Chr$(i) & ":\"
End If
End If
Next i
Public Function DriveType(sDrive As String) As String
10 On Error GoTo e
Dim sDriveName As String
Const DRIVE_TYPE_UNDTERMINED = 0
Const DRIVE_ROOT_NOT_EXIST = 1
Const DRIVE_REMOVABLE = 2
Const DRIVE_FIXED = 3
Const DRIVE_REMOTE = 4
Const DRIVE_CDROM = 5
Const DRIVE_RAMDISK = 6
20 sDriveName = GetDriveType(sDrive & ":\")
30 Select Case sDriveName
Case DRIVE_TYPE_UNDTERMINED
40 DriveType = "unknown"
50 Case DRIVE_ROOT_NOT_EXIST
60 DriveType = "non-existent"
70 Case DRIVE_CDROM
80 DriveType = "CD-ROM"
90 Case DRIVE_FIXED
100 DriveType = "local"
110 Case DRIVE_RAMDISK
120 DriveType = "RAM"
130 Case DRIVE_REMOTE
140 DriveType = "remote"
150 Case DRIVE_REMOVABLE
160 DriveType = "removeable"
170 End Select
180 Exit Function
Yes, a device connected via USB contains a controller, and that controller presents itself to the host adapter as one or more kinds of USB devices.
Windows has drivers for common types, such as HID (Human Interface Device - keyboards, mice, etc.) or Mass Storage (external drives).
If you have a less common device, then the manufacturer supplies drivers to allow programs on the PC to communicate with it. Some of these present themselves as COM: ports, others are highly specialized and so the manufacturer must supply some kind of interface DLL because Windows has no built in support for the device.
I refer to the first of the two responses posted above by DILLETANTE.
Leaving aside the somewhat derogatory tone of Dillatante's post, these further thoughts are submitted for constructive comment.
USB is indeed a data bus as opposed to a 1 to 1 serial link such as RS-232. However it has a lot in common with RS-232. If you consider the USB connection to a single external device - whatever it may be - there is a serial data stream to the device and a serial data stream from the device. The fourth wire is just the +5v power.
If it is indeed possible to obtain adaptor units which plug into a RS-232 port and which provide a USB type external connection, then in principle it might be possible for a RS-232 serial data string sent to that port to be onward routed by the adaptor to the RS-232 device and vice-versa. If that were possible, perhaps a single USB device could appear to the PC as if it were a RS-232 device, and hence MSCOMM could talk to it via that RS-232 numbered COM port.
Of course such a system could not take advantage of the very high speed available with the USB, but potentially it might work to the limits of 232 which are sufficient for a large number of purposes. I have not read of a minimum serial data speed limit for USB operation (only of maxima depending whether 1.0, 2.0 or 3.0).
It would, as stated above in this thread, be necessary to learn from the USB device manufacturer just what serial codes must be sent to their device and how to interpret what comes back. Therefore one would effectively have to write what amounts to a device driver - but that is not beyond the bounds of possibility given a co-operative supplier.
If this could be achieved, then the interfacing of VB6 etc. with single USB devices might be possible, and surely that would be a very useful thing?
camoore
This is a futile topic that will end the same way all USB (Specialized) Device threads end.... D.O.A! As stated, without a SDK you're rowing your boat with one oar.
We need a one link click for these posts. One that will bring up every (USB/Unknown Device) thread. This will save typing the same thing repeatedly.
My personal recommendation for those working with microcontrollers is to only purchase RS232 compatible PICs and devices, unless you can insure a VB6 SDK . They work just fine with a USB/RS232 converter dongle. Absolutely nothing has to be changed in your MSComm routines. Ignore this tip if you will, but you're going to be rowing forever. :rolleyes:
No, you have seen USB to 9 port RS232 adapters. The reverse is counter productive and about as useful as a screen door on a Submarine. If you find one, post the link here an I will stand corrected. The ones that I've found were mis-stated.Quote:
Originally Posted by camoore
Derogatory? I wasn't the one who sauntered in here and started blaming this all on "shortcomings of VB6." ;)Quote:
Originally Posted by camoore
Move to .Net? Please? :p
you can also get usb to parallel adaptors, but my experience is they only work with parallel printers, not any other parallel devices
I can absolutely vouch for those adaptors which connect by USB to the PC and provide 1,2 or 4 9-pin RS-232 ports. Given suitable drivers - which usually come with the adaptors - the RS-232 ports are assigned COM port numbers and the MSCOMM of VB6 communicates with them perfectly.
However what would be required here, were such a beast to exist, is the inverse of such adaptors. There are certain uses for a screen door in a submarine, and by the same token such an inverse adaptor would have significant potential use in that it just might allow VB to communicate directly with a USB peripheral as the original post asked.
In researching this topic, I came across this URL at which code to enable VB to communicate directly, 2-way, with a USB device is described and a VB code example is provided. In this case the device is one of a range of data input / output modules manufactured by the company. I believe that this particular application makes use of the HID (Human Interface) feature of Windows (98SE plus) which normally handles relatively slow USB traffic to/from keyboards, mice and game consoles. However this example does show, I think, that USB interfacing 2-way directly from VB code is possible. Just how many USB devices would be suitable for this HID type routine I can not say.
http://www.ontrak.net/ADUSDK/AduQuickStart-VB.html
CD Drive's point about only buying RS-232 interfacing devices is, of course, very well made. However, the writer of the original post to this thread obviously had a reason for asking the questiion he did - and yes, there certainly has been a number of previous threads at this forum of a similar nature.
Those such as Dilletante and CD Drive of very high expertise are certainly well placed to say what is and is not possible. However their comment on the code described at the above URL would be of interest.
camoore
There is no such thing as a piece of hardware or software which does not have some sort of limitation. The fact that VB6 does not immediately have the equivalent of a MSCOMM to communicate with USB devices is a limitation, but not a criticism of what is a very versatile and flexible programming language. However, when limitations are encountered it surely behoves us to try to work around them?
1. My original point was that you cannot just strip the end of a USB cable and add a buffering transistor and a relay the way you can with a COM: port cable.
2. If you want to control a toaster via USB you need some sort of inteilligent device and Windows driver software presenting an API. If you buy a USB device providing RS-232 ports, great. If you buy one providing control relays even better.
But the questions asked looked a lot more like (1.) above. Question (2.) is a hardware question, not a programming question. Since it not a VB6 question at all per se maybe the General Developer forum would have been better. :eek:
That's not what you stated. You described the inverse. Is this a question or a statement? You're quote:Quote:
Originally Posted by camoore
Another of your quotes:Quote:
If it is indeed possible to obtain adaptor units which plug into a RS-232 port and which provide a USB type external connection,
So what's the argument? That's a SDK specific to their series of devices and their DLL for same. You just proved the point that has been made repeatedly regarding the need for the manufacturer's SDK's!Quote:
In researching this topic, I came across this URL at which code to enable VB to communicate directly, 2-way, with a USB device is described and a VB code example is provided.
Just for the record: I'm not attempting to demean you in any way. I'm just pointing out that we have been down this road many times before. The road always leads to a dead end street. The street sign says "Get SDK".
Until the day comes that someone writes an app that scans the BUS and prints out a SDK for anything it finds (pipe dream?), the programmer must rely on the manufacturer to supply one.
Gentlemen (or ladies?) I feel that it is time to terminate the current discussion in this thread, unless a new contributor would care to add further helpful information.
For CD Drive, I comment that I have never been in any doubt as to the difference between a USB connected device which provides RS-232 ports (commonly available and which I confirm can work very well with VB) and the suggested converse which would be something which plugs into a RS-232 port and provides a USB interface. I believe that if CD Drive were to re-read carefully my posted replies, it would be seen that I was at pains to make the appropriate differentiation between the two opposing concepts. Maybe the latter is just a "holy grail", but were it to be achievable it would be very useful surely? One can not but ask and suggest.
I regret somewhat that contributors to this excellent forum can apparently become so worked up and rather harsh in their subsequent postings about the stated opinions/questions of others. We all have to learn somehow - in part that is why we join such forums. Doubtless we all, depending upon our particular professional backgrounds, have something which we can teach to the benefit of others. It behoves us all to remember that just as any piece of hardware or software probably has limitations, so do we ourselves. Just because something has not been done before does not per-se mean that it can not be achieved.
It is to be noted that the opriginator of this thread does not seem to have responded further. For some reason, recent thread posts have not automatically been e-mailed to me by way of notification. Might this have also applied to the originator?
camoore
Some time ago I stopped getting email notifactions, so I changed my email address to a gmail account that forwards to the one i was using in the first place. Don't know why but it worked.Quote:
Originally Posted by camoore
Thank you ISNOEND07, for this message and for your contribution to the originator's thread.
This is the first time I have encountered problems with not being notified about thread replies /updates. Will bear in mind your helpful comment.
camoore
It could be just a hiccup in the system, or is it possible that your spam settings thinks it's spam?Quote:
Originally Posted by camoore
I checked that VBForum messages were not getting classed as SPAM, and they were not. Today the notification came through quite OK, so it must be assumed that there was, as Cd Drive suggests, a system hiccup.
camoore
camoore, glad to see that you're now receiving notifications. I also hope that this thread has not left you with hard feelings. BTW, it's CDRIVE not Cd Drive.Quote:
Originally Posted by camoore
It was not my spam filter eitherQuote:
Originally Posted by camoore
In thinking back I posted a question:
Why have stopped getting email notifactions ?
Answer: "Try using a different email address" and it worked
Don't remember what portion of this forum I posted to.
Apologies CDRIVE for getting your handle wrong.
The e-mail notification failed for me again in respect of the last two posts. Now today I unsubscribed myself (stupid) from the thread by clicking on the wrong URL, so can not be certain of receiving anything.
However there was a problem with notification, which hopefully a moderator or forum supervisor could look into? I do not think this thread the right place to continue discussion of a general forum operating glitch.
camoore
Maybe they can help you at Forum Feedback.
Good luck.
Having researched the subject of USB i/o communication further, I am pleased to be able to inform subscribers to this thread that THERE IS at least one device available which would enable direct communication between VB and a USB device. It is called the ROOT 2 and is made by RPM Systems in the USA. This device is intended for the test and software development of usb equipments. It connects to the PC via either a 232 serial port or 10/100 Ethernet. The ROOT 2 then provides a USB connector to which the USB equipment is plugged. It is LOW, FULL and HIGH speed compatible, USB 1 and 2. They also say that a hub may be connected to it, so it would seem that several USB equipments can be dealt with more or less simultaneously through it as a sort of secondary bus.
Via. the 232 port, correctly ordered packets can be sent to the USB equipment (USBE) and data from that equipment can be read back into the PC. ROOT comes with software which enables the user to generate desired messages to be sent to the USBE and to view the data sent back by the USBE.
In that the interface both ways with the PC is a 232 serial port, the possibility of using MSCOMM to talk 2-way with a USBE seems feasible. It would of course be necessary to know the data protocol employed by RPM Systems for the control of their ROOT device, and also the packet data convention used by the USBE.
However, this does seem something of a step forward in that 2-way comms. with a specific USBE to/from VB using MSCOMM becomes possible.
This does not of course immediately extract a SDK for that USBE, but once into VB there exists the possibility of writing analytical programs to determine the data interface definition of the USBE (especially if the USBE manufacturer co-operates in the provision of information)..
It would always be necessary to have the ROOT 2 in place as an element of the system. This is not immediately a means of getting VB to talk to a USBE connected to the standard USB of the PC.
So not a magic wand, but I thought an interesting find.
A drawback is the price - upwards of $2300 per ROOT 2 device. But where there's one there may be others, and less costly.
Here is an extract from a message I got from the manufacturer which contains URL's to further information about ROOT 2 :-
It provides you the capability to interface with a device at whatever level you choose. It allows you to break transfers down to the single transaction level, but it also provides capabilities to independently manage large transfers. It provides an automatic mode, in which it will automatically recognize device connections, and enumerate and configure devices as they are connected to the bus. Even for simple testing applications, this can save you a lot of programming by putting the device in a configured state (configured on the USB, that is) before you take over with device-specific programming.
Root 2 allows you to directly control Suspend/Resume, USB Reset and bus power. It allows you to force full speed operation for high-speed devices, set Vbus voltage levels, measure Vbus current and more.
We provide libraries to facilitate interfacing of your own application software to Root 2, via either RS-232 serial port or ethernet.
Here are some links to more detailed Root 2 information:
Info sheet: http://www.rpmsys.com/root_flyer.pdf
User's Guide: http://www.rpmsys.com/Root2_interface_spec.pdf
RootComm Library: http://www.rpmsys.com/RootComm_HowTo.pdf
RootScript Library: http://www.rpmsys.com/RootScript_HowTo.pdf
The User's Guide provides the most complete description of the Root 2's capabilities, including its native communication protocol. The RootComm library provides and API-level interface which facilitates implementing the Root 2's command set..
I hope this info. will be of interest to the VB Forum.
camoore Wales, UK