Dear Forum,
It is know that the inter command speed is limited to 20ms (?) I was wondering if two K8055s connected to two USB ports would get around this? i.e. if I wanted a digital signal to switch in milliseconds (or sub-milliseconds using windows timers) could I send a command to one board and then a short while later, another command to the other board?
Regards,
ROC_UK
Very interesting point of view.
I had to make a test.
Indeed, it seems that it is possible to avoid the 10ms USB limit.
Using the following code I got the time between the actions on the two cards to about 1.9ms.
[code]SetCurrentDevice (0);
SetDigitalChannel(1);
SetCurrentDevice (1);
SetDigitalChannel(1);
SetCurrentDevice (0);
ClearDigitalChannel(1);
SetCurrentDevice (1);
ClearDigitalChannel(1);[/code]
This oscilloscope screenshot shows the result:
Thanks VEL255, just as I thought. I was unable to do this myself not having two boards and being 200 miles from my lab.
Phew! Saves me using a micro-controller on the 68K line which is prone to damage and doesn’t have o/c outputs.
Shame that Velleman don’t supply functionality to split each digital line into 8 virtual USB channels (each USB line can take 127 devices).
Regards,
ROC_UK.
After some further tests, it seems that this “trick” is platform and operating system dependent.
It works fine under Windows 2000 and XP in an old desktop PC.
Doesn’t run well under Windows Vista x32 in a laptop.
Here is the result:
Works fine under Windows 7 x64 if an external USB hub is used and both of the K8055 cards are connected to the HUB. Otherwise about similar result as in the Vista PC.
I was thinking the same - whether to run the cards off a hub or two “different” USB ports.
Do you have a profiler? Could you work out where the delay is in the dll code?
It would be nice if both devices could be opened simultaneously but the dll works on a per device basis…
Failing that, two processes or even threads with inter-process communication and separate memory spaces (so each gets its own "copy" of the dll) could make it even faster. Then again, does the dll block multiple instantiation...?
One could possibly have two copies of the dll ! K8055D_A.dll and K8055D_B.dll ! It would be nice to re-link the code so that code for one card could have calls ending _A and the second _B, that way two devices could be open at the same time. In fact if assembler is used and one gets a non-interruptable time-slice form the OS, some very fast transitions could be possible.
It would be nice if Velleman had allowed virtualisation of the digital ports, though, to say split into 2 x 4bits and two virtual cards. It would probably need two (PIC?) micro-controllers per board though.
Thanks.
[quote]Do you have a profiler? Could you work out where the delay is in the dll code?[/quote]I think the delay is in the USB system - not in the DLL…
[quote]One could possibly have two copies of the dll ! K8055D_A.dll and K8055D_B.dll ! It would be nice to re-link the code so that code for one card could have calls ending _A and the second _B, that way two devices could be open at the same time. In fact if assembler is used and one gets a non-interruptable time-slice form the OS, some very fast transitions could be possible.[/quote]Using two copies of the DLL seems to work too.
I tested it with a simple C# example program.
Here a snippet of the source:
[code] public sealed class api1
{
[DllImport(“k8055d1.dll”)]
public static extern int OpenDevice(int devNumber);
[DllImport("k8055d1.dll")]
public static extern void CloseDevice();
[DllImport("k8055d1.dll")]
public static extern void ClearAllDigital();
[DllImport("k8055d1.dll")]
public static extern void SetAllDigital();
}
public sealed class api2
{
[DllImport("k8055d2.dll")]
public static extern int OpenDevice(int devNumber);
[DllImport("k8055d2.dll")]
public static extern void CloseDevice();
[DllImport("k8055d2.dll")]
public static extern void ClearAllDigital();
[DllImport("k8055d2.dll")]
public static extern void SetAllDigital();
}
private void button2_Click(object sender, EventArgs e)
{
api1.SetAllDigital();
api2.SetAllDigital();
api1.ClearAllDigital();
api2.ClearAllDigital();
}[/code]
I was expecting the simultaneous response from both of the cards, but there is still the 2ms delay. This is the result:
[quote]It would be nice if Velleman had allowed virtualisation of the digital ports, though, to say split into 2 x 4bits and two virtual cards. It would probably need two (PIC?) micro-controllers per board though.[/quote]This may be possible with the newer microcontrollers. Maybe in the future products…
Thank you for all your suggestions. - Will be considered when the future products are developed. 
Yes thank you too. I look forward with keen interest to future product developments. Nice little board.
Some quick thoughts, is the K8055 USB1.0 or 2.0? Is this related to the frame delay?
The K8055 is a USB 1.1 low speed HID class device.
The speed seems to be same if connected to USB 2.0 port.
'Fraid connecting a USB1.1 device to a USB2.0 device won’t make a difference. The protocol knows it and drops the speed and frame rate from 125us to 1ms. Possibly the 2ms figure you are getting is due to an intervening ACK or SYNC - on a cursory look at the USB protocol. It could also be the result of it not being at the top level of the tree with further intervening USB protocol meta-data.
I was wondering if operating on “another” USB port might help but I think, unless separate root controllers, they all part of the same topology. The splicing/multiplex approach won’t work. Possibly on some old desktop with PCI connector I could connect a spare USB card and find out.
Anyway, I have bought another K8055 and look forward to trying it out with the existing one. Mind you, I could make use of the counters - if that’s what they do, send a pin high when finished.
It would be nice if the K8055 had some kind of deep buffer/sequencer on board but I am just a bod peeing into the tent/adding my two-cents worth. Maybe with a little bit of event and branch logic. It could then respond on a much faster clock rate.
I forgotten how to beat the 20ms speed limit by pre-loading commands and then sending down to achieve a 10ms between commands. I do recall something like this. I’d have to track it down on this forum.
[quote]I was wondering if operating on “another” USB port might help but I think, unless separate root controllers, they all part of the same topology.The splicing/multiplex approach won’t work.[/quote] This seems to be the case.
[quote]Possibly on some old desktop with PCI connector I could connect a spare USB card and find out.[/quote]I made a test with an old desktop PC with a PCI-USB card with two USB (1.1) sockets. The results were identical to the previous ones - the 2ms delay seems to be there.
Puzzling. Thanks.