Driving the Maestro via USB by calling driver DLLs - how?

Perl, Ruby, Visual Basic, VBScript, JScript and others all feature ways to make arbitrary calls into windows DLL libraries.

Here, for example, is perl reading the XBox360 wireless joystick data in Windows7:

my $joyGetNumDevs=Win32::API->new('UsbWrapper', 'int joyGetNumDevs()');
print $joyGetNumDevs->Call();

Is one of the Pololu DLL’s able to be loaded and called in a similar way, and if so - which one(s), and what is the list of functions available and their paramaters?

I notice all these in the driver folder - how do I find out what functions are in them, and how to use them?


Hello, Chris.

I don’t think you will be able to use the Pololu DLLs in a similar way because those dlls (Bytecode.dll, Sequencer.dll, UsbWrapper.dll, Usc.dll) are actually .NET assemblies rather than Win32 DLLs. Some of those languages might have ways of interacting with .NET, especially Visual Basic which is a .NET language. If you want to control a Maestro from Visual Basic .NET, you can see the Pololu USB SDK for example VB .NET code. It also has example C# and Visual C++ code. This code uses the Maestro’s native USB interface via Usc.dll and UsbWrapper.dll, rather than the virtual COM port.

For Sequencer.dll and Usc.dll, you can see the source code by looking in the Pololu USB SDK. For UsbWrapper.dll and Bytecode.dll, there is some way to see the list of functions available by adding them as a reference to a Visual Studio project, but I’m not sure exactly what buttons you have to click to do that. You should just look at our example code in the Pololu USB SDK; that should be sufficient for your needs.

Have you seen the section of the Maestro User’s Guide entitled “Writing PC Software to Control the Maestro”?


Hi David - thanks for that.

Looks like we’re nudging closer to a solution here… I don’t have any SDKs or IDEs or anything installed (most Windows users do not), and the general idea was to upload this to CPAN (the perl repository where other people can grab working solutions to small problems like this)… so sorting it out without needing a compiler is my ultimate goal.

perl can do .NET as well:-

perl -e "use Win32::OLE; $hl = new Win32::OLE('HelloDot.HelloWorld') or die $!; $hl->SayHello();"

(and from memory, I think VBScript and JScript and others can too). Got any ideas for me to test this with - like - do any of the DLLs make their stuff public, and what’s a good basic “test” to experiment with (eg: is there a call of any kind to return the DLL’s version number or something? Anything that’s independent of “needing stuff plugged in”, or at least uses few or not input paramaters to start with)?


A good first step is to call Usc.getConnectedDevices(), a public static method in the Usc class in Usc.dll. It returns a List.

I think you should make an exception for the Pololu USB SDK. At the very least you should download it so you can see the source code of the Usc class, which represents the native USB interface of the Maestro, and also see our example code that uses the Usc class. I think this will be the easiest way for you to learn how to use our DLLs.


Does anyone have any COM or ActiveX or OCX interface DLLs they can share with us lowly “script programmers”?

At the end of the day, installing a 700+ meg $$$-expensive compiler, learning a whole new language (or worse - new operating system too), wading through hundreds of lines of complicated interface code, and switching our brains into a new coding paradigm, to produce a multimegabyte executable file that won’t work without more hundreds of megs of O/S updates to support it does seem, at least to me, like an extreme waste of everyones time, effort, and resources, when at the end of the day, all that anyone really needs is one line of code

I have done this kind of stuff, literally in just 1 line, on my LabJack U12 - it’s increadibly liberating to spend a whole 1 minute getting that line in place and the device working :slight_smile:


One post ago you said “perl can do .NET as well”, but now it seems like you don’t want to use .NET. I’m not sure I understand.

I think you are exaggerating the inconveniences of .NET because you don’t really know that much about it.

Microsoft Visual Basic 2010 Express, Visual C# 2010 Express, and Visual C++ Express are all free, so you don’t need a $$$-expensive compiler.

If perl really is capable of calling .NET functions and storing references to .NET objects, then you don’t have to learn a new language and you don’t have to use the compiler. I’m not sure if perl can do this.

To run .NET code you need to install the right version of the .NET framework, which is currently 3.5 for our Maestro libraries. The download is 231 MB.

The Maestro has the virtual COM port, which everyone can use, but I have been thinking for a while that it would be nice if we had a more primitive type of library for talking to the Maestro’s native USB interface. I was thinking it would just be a plain old Win32 DLL with C functions in it because that seems to be the lowest common denominator of library in Windows. It would have functions something like:

struct MaestroInfo
  const char * serialNumber;
  uint16_t usbProductId;   // specifies which type of Maestro it is

MAESTRO_RESULT maestroListCreate(MaestroInfo ** list, uint32_t * length);
void maestroListFree(MaestroInfo * list);
MAESTRO_RESULT maestroOpen(MaestroInfo * maestro, MaestroHandle ** handle);
void maestroClose(MaestroHandle * handle);
MAESTRO_RESULT maestroSetTarget(MaestroHandle * handle, uint8_t channel, uint16_t target);
MAESTRO_RESULT maestroSetSpeed(MaestroHandle * handle, uint8_t channel, uint16_t speed);

Does that kind of thing work for you? It would require you to hang on to a pointer in your perl program and not modify it.

But we would probably add some easier functions that open the handle, send the command, and close the handle all at once but these would be less efficient:

MAESTRO_RESULT maestroSetTarget(char * serialNumber /* can be null */, uint8_t channel, uint16_t target);

I don’t know much about COM, ActiveX, or OCX. Would one of those be better than a Win32 DLL, and why?


Weirdness - I think maybe a post of mine from a different forum got redirected to here?

Anyhow - my belated reply… I’ll investigate the .NET thing first, but aside from that - yes. Your “C” idea sounds ideal. Perl’s got this thing called “.xs” which lets people like me weave native perl modules from C source code, so that other programmers don’t need to worry about pointers and C structures and so forth - they just code their perl, and it all works :slight_smile:

Stay tuned…

I’m glad you approve of my API. If we made this DLL, would you be able to build a .xs thing just using my DLL and header file, or would we have to do something special to support perl?


Hi David,

The DLL should be sufficient, however, I think with very minimal effort, you can build your DLL so that it can use used by all different kinds of windows programs - everything from Excel spreadsheets, to VB scripts, to Web pages/JavaScript, as well as perl and C and almost all other languages. I’ve done this myself (written DLLs that are used by web pages and Excel), and of course, I’ve used other DLLs like this in my programming… I’m pretty good when it comes to doing the “glue” that makes everything work together.

The only “snag”, is that it’s been 5 or 10 years since I messed with this stuff seriously, and I never really knew all the correct names for it back when I did anyhow. I’m not sure if you’re needing to write a COM interface, or an OCX, or an ActiveX or whatever (sorry!). On the upside, I can (did already) tell you how this stuff gets used, so perhaps you or someone else here can infer the name of what you need to write from the way it gets called?

“OLE” (Object Linking and Embedding) is how your DLL can let other people use itself. Here’s how perl makes use of that: xav.com/perl/faq/Windows/Act … faq12.html

And here is how VBScript does it:-
msdn.microsoft.com/en-us/library … =office.12.aspx

Here is the perl equivalent of the first example in the VBScript page above:-

perl -e “use Win32::OLE;$ie=Win32::OLE->new(‘InternetExplorer.Application’) or die $!; $ie->{‘Visible’} = 1; $ie->Navigate(‘www.pololu.com’);”

Basically - what I’m trying to say is - with minimal effort, you can make your own DLL behave like the above (perhaps called a “COM Application?”), and then everyone can use it - not just “C” programmers with compilers :slight_smile:

Finally - while this is probably useless to you because you don’t program in perl… perl itself is able to build COM DLLs with minimal effort, which lets other people use them like I’ve described above. I guess the “worst case scenario” here, is that you fail to grok COM, release some DLL, then I can write a perl .XS interface to it, and use perl to build the DLL that lets everyone else use your code. Nightmare overhead in DLLs… but it would work, and only take a few dozen lines of code at my end :slight_smile:

Do you have strong mac, linux, and Windows support in your products at the moment? If not, I’m happy to collaborate with you to add at least the perl modules you’ll need into your software resources that you can give to other people. I am presently busy experimenting with iOS serial interfaces as well, so there’s a slight chance that I could help you build an “Apple certified” connector that would allow anyone with an iPod, iPad, or iPhone to drive your devices directly via apps (FYI - the apple dock connector does serial I/O, albeit using 3.3v TTL, so an interface cable could be as bog-simple as a plug at one end, and a 3-wire servo-style connector at the other. Stay tuned…)

p.s. I wrote the perl drivers for the Labjack, for Windows, Mac, and Linux, so I’m not completely stupid, like my orignal messages implied…

search.cpan.org/~cdrake/Device-L … LabJack.pm


Grumble. Typical Microsoft to pick pointlessly generic names that are totally meaningless… anyhow… I really don’t know if I mean “COM” or “ActiveX” now (and I suspect my first example - the one for using Xbox joysticks - is niether of those anyhow). The way to create a DLL from a perl script is by using a thing called “perlctrl”:


which is telling us that it’s creating a “control” (whatever that is… I thought such things were like input boxes and stuff…) which is an ActiveX thingamahwhosit.

So… please don’t “Flame” me for using all the wrong names here. Blame Microsoft, for picking stupid ones to start with…

Oh - and while I don’t know what they’re called, I do of course know how to make and use them nevertheless…