How to tell when an ocx method call is finished?

[mike]

I'm trying to make the Softmark USB to GPIB converter work.
The vendor is unwilling to supply any documentation of sample programs
or ANYTHING other than a crippled demo program.
I've fixed the hardware, but the firmware doesn't support my fix.
I've been experimenting, trying to reverse engineer the .ocx file that
came with it.

Doing a GPIB handshake for every byte in visual basic is excruciatingly
slow, but I'd like to use this turkey for something.

Problem is that there's an ocx method to write the ports.
But it can take as much as 300ms for it to happen.
And there's no feedback, so I have to poll the registers,
which ain't valid for up to 300ms.

So, is there a way to tell when the method has finished?
I've used wait for single object to call programs
using the shell. Is there something similar that I can
use on an unknown "black box" call thru an ocx?

Thanks, mike

[Auric__]

Post by mike
I'm trying to make the Softmark USB to GPIB converter work.
The vendor is unwilling to supply any documentation of sample programs
or ANYTHING other than a crippled demo program.
I've fixed the hardware, but the firmware doesn't support my fix.
I've been experimenting, trying to reverse engineer the .ocx file that
came with it.
Doing a GPIB handshake for every byte in visual basic is excruciatingly
slow, but I'd like to use this turkey for something.
Problem is that there's an ocx method to write the ports.
But it can take as much as 300ms for it to happen.
And there's no feedback, so I have to poll the registers,
which ain't valid for up to 300ms.
So, is there a way to tell when the method has finished?
I've used wait for single object to call programs
using the shell. Is there something similar that I can
use on an unknown "black box" call thru an ocx?

I'd get my money back. They supplied you with something, but refused to tell
you how to use it? Refund, hands down.

[ralph]

Post by mike
I'm trying to make the Softmark USB to GPIB converter work.
The vendor is unwilling to supply any documentation of sample programs
or ANYTHING other than a crippled demo program.
I've fixed the hardware, but the firmware doesn't support my fix.
I've been experimenting, trying to reverse engineer the .ocx file that
came with it.
Doing a GPIB handshake for every byte in visual basic is excruciatingly
slow, but I'd like to use this turkey for something.
Problem is that there's an ocx method to write the ports.
But it can take as much as 300ms for it to happen.
And there's no feedback, so I have to poll the registers,
which ain't valid for up to 300ms.
So, is there a way to tell when the method has finished?
I've used wait for single object to call programs
using the shell. Is there something similar that I can
use on an unknown "black box" call thru an ocx?
Thanks, mike

Not really. Depends on the threading model, which for VB likely means
a single thread and it will take as long as it takes.

You might try WinDbg ...
http://msdn.microsoft.com/en-us/windows/hardware/gg463009
This will allow a lot of peeking.

There are various ICE products available. Most need two computers and
are expensive. $200 and up.

But Frankly I'm with Auric ... why waste time on it? Get a refund. <g>

-ralph

[mike]

Post by ralph

Post by mike
I'm trying to make the Softmark USB to GPIB converter work.
The vendor is unwilling to supply any documentation of sample programs
or ANYTHING other than a crippled demo program.
I've fixed the hardware, but the firmware doesn't support my fix.
I've been experimenting, trying to reverse engineer the .ocx file that
came with it.
Doing a GPIB handshake for every byte in visual basic is excruciatingly
slow, but I'd like to use this turkey for something.
Problem is that there's an ocx method to write the ports.
But it can take as much as 300ms for it to happen.
And there's no feedback, so I have to poll the registers,
which ain't valid for up to 300ms.
So, is there a way to tell when the method has finished?
I've used wait for single object to call programs
using the shell. Is there something similar that I can
use on an unknown "black box" call thru an ocx?
Thanks, mike

Not really. Depends on the threading model, which for VB likely means
a single thread and it will take as long as it takes.
You might try WinDbg ...
http://msdn.microsoft.com/en-us/windows/hardware/gg463009
This will allow a lot of peeking.
There are various ICE products available. Most need two computers and
are expensive. $200 and up.
But Frankly I'm with Auric ... why waste time on it? Get a refund.<g>
-ralph

Thanks, for the inputs, I'll check it out.
I bought it used, so return is not an option.
I'm not concerned with how long the command takes.
I just want to know when it's done, so I can do more stuff.
I've got read and write queues stacked up and the data is
all out of sync.
Peeking at a debugging tool may not help. I need real time
data at run time for the program to act on.
I'd just wait, but it takes half a second on some stuff.
Not speedy enough to be useful. And waiting too long doesn't
work either. The bus may be timing out????

Yes, I know it's not cost effective to waste time on it.
I just want to figger it out and make it work.
Thanks, mike

[Farnsworth]

Post by mike
I'm trying to make the Softmark USB to GPIB converter work.
The vendor is unwilling to supply any documentation of sample programs
or ANYTHING other than a crippled demo program.
I've fixed the hardware, but the firmware doesn't support my fix.
I've been experimenting, trying to reverse engineer the .ocx file that
came with it.
Doing a GPIB handshake for every byte in visual basic is excruciatingly
slow, but I'd like to use this turkey for something.
Problem is that there's an ocx method to write the ports.
But it can take as much as 300ms for it to happen.
And there's no feedback, so I have to poll the registers,
which ain't valid for up to 300ms.
So, is there a way to tell when the method has finished?
I've used wait for single object to call programs
using the shell. Is there something similar that I can
use on an unknown "black box" call thru an ocx?

The method is "done" when the call returns. Well made stuff should have an
event to trigger when the work was actually done. Try pressing F2 to bring
up the Object Browser, select the OCX, and see if it provides any events.

[mike]

This post might be inappropriate. Click to display it.

[Farnsworth]

Post by mike
Seems that VB is not waiting for one method to complete before executing
another..

No, it's the OCX that is doing that, not VB. It can initiate the action and
retunes immediately while doing the work in the background. A well designed
OCX should have an event like "Complete" or "Status" that fires when the
work is actually finished.

Post by mike
There's no documentation and I can't find anything in the Object Browser
that suggests there might be an indication that the ocx command is complete.

Then find another hardware, or perhaps spend weeks in learning how to talk
to USB directly from VB, and decode what being sent and received. There are
free tools that record everything being sent and received to the USB port.
See "Software-only analyzers" at this link:

http://www.lvr.com/development_tools.htm

Main page:

http://www.lvr.com/usb.htm

The USB sniffer might give you some idea of what's going on. There are other
useful tools in the first link that you may want to explore.

Another option, is to use a parallel port solution, and I think you need two
ports at least to cover all signals, but I am not sure. This page includes a
DLL and a sample to allows you talk to "any" port from VB6:

http://www.lvr.com/parport.htm

Look for the heading "Programming Tools for Port I/O and Interrupts".

[mike]

Post by Farnsworth

Post by mike
Seems that VB is not waiting for one method to complete before executing
another..

No, it's the OCX that is doing that, not VB. It can initiate the action and
retunes immediately while doing the work in the background. A well designed
OCX should have an event like "Complete" or "Status" that fires when the
work is actually finished.

Post by mike
There's no documentation and I can't find anything in the Object Browser
that suggests there might be an indication that the ocx command is complete.

Then find another hardware, or perhaps spend weeks in learning how to talk
to USB directly from VB, and decode what being sent and received. There are
free tools that record everything being sent and received to the USB port.
http://www.lvr.com/development_tools.htm
http://www.lvr.com/usb.htm
The USB sniffer might give you some idea of what's going on. There are other
useful tools in the first link that you may want to explore.
Another option, is to use a parallel port solution, and I think you need two
ports at least to cover all signals, but I am not sure. This page includes a
http://www.lvr.com/parport.htm
Look for the heading "Programming Tools for Port I/O and Interrupts".

Thanks for the inputs.

I've failed to communicate my objectives.
I'm not interested in learning about GPIB or alternative ways of talking
to it.
I already implemented a Serial/GPIB converter based on a PIC processor
and the VB programs to talk through it to GPIB. It works fine.

I have this turkey undocumented Softmark GPIB interface and have become
obsessed with making it work. That launched me into a study of
techniques for
analyzing and working around deficiencies in somebody else's
undocumented code.

I can monitor GPIB bus traffic with a logic analyzer.
I can't monitor USB traffic.
I've downloaded and tried a bunch of free or demo protocol monitors. I
can see a LOT of stuff going back and forth,
but nothing that I can relate to the 3 bytes of payload data being sent
by my test program.
All looks like interrupt and "heartbeat" stuff that happens even when
I'm not accessing the USB.

The "howitworks" page for usblyzer says that the data is embedded in the
IOCTL_INTERNAL_USB_SUBMIT_URB.
But I can't find anywhere in the user interface to trace that info?
It's missing from the list of checkboxes for things to monitor.

The Softmark shows up as a HID device.
Can you recommend a specific free or trial tool that can show me the
payload data being sent across the USB?

I really don't care about
all the USB protocol stuff, 'cause there's nothing I can do about it
anyway. I just want to see what data the undocumented demo program
is sending thru the undocumented .ocx over USB to the undocumented firmware
in the interface that controls the GPIB that I can view.

Yes, I know....that's why I used the word "obsessed".
Thanks, mike

[Farnsworth]

This post might be inappropriate. Click to display it.