Jump to content

As of July 17, 2015, the LabJack forums here at forums.labjack.com are shut down. New registrations, topics, and replies are disabled. All forums are in a read-only state for archive purposes.

Please visit our current forums at labjack.com/forums to view and make new posts. To post on the current forums, use your labjack.com login account. Your old LabJack forums login credentials have been retired. There are no longer separate logins for labjack.com and LabJack forums.


Photo

Correct semantics in exodriver?


  • Please log in to reply
11 replies to this topic

#1 dsigma

dsigma
  • Members
  • 2 posts

Posted 06 January 2011 - 12:57 PM

I have 2 concerns regarding the exodrivers...

1) I was reviewing the exodriver source code (labjackusb.c) and found multiple cases where exit(1) was being called. Unfortunately, this poses a problem for any application using the labjack exodriver as the application cannot correctly do application specific cleanup and handling in the event of a labjack failure. The labjack libraries do not know the context in which they are executing, and thus, cannot correctly determine if exiting the process is a safe or correct thing to do. They should be returning an error code, and leaving the decision of how to handle the error up to the caller of the function.

2) We'd like to use the labjack for some hardware in the loop system integration testing, and our software is using libusb-1.0 to communicate with our hardware. In reviewing the labjack code, I see that it is using the default libusb context (note the NULL being passed to the libusb_init() and libusb_exit() functions). Our software also uses the default context. This is going to cause a problem when I go to link and initialize the application as the two pieces of software will be manipulating the libusb context of the other piece of software. Realizing this, I have to go thru our code and define and use a context specific to our application, but the labjack exodriver should also be doing the same thing if it expects to integrate with 3rd party software. More commentary can be found here: http://libusb.source...group__lib.html

Questions? Comments? Thoughts?

Thanks,
-d

#2 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 06 January 2011 - 07:06 PM

1) The exit calls rarely happen, but I agree the Exodriver should not terminate programs on its own. 2) Thanks for pointing this out. We overlooked this, but you are correct about using the default context. To prevent interference with others using libusb within the same program a unique context should be used. Your comments are appreciated. I am currently updating the Exodriver code to resolve these issues, and will post again when it is available for download.

#3 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 06 January 2011 - 07:51 PM

Exodriver v2.04 is available on GitHub. This version addresses the issues you brought up.

#4 dsigma

dsigma
  • Members
  • 2 posts

Posted 06 January 2011 - 09:44 PM

Exodriver v2.04 is available on GitHub. This version addresses the issues you brought up.


Wow, that was fast! I think that literally the fastest driver update response I've ever seen... Nice work and thank you! :)

Well I guess while I'm in the mode of posting requests, maybe I can throw out and idea and see if has any appeal...

Our company sells a USB wigit. We use libusb-1.0 to interface with our USB wigit. We are using the libusb-pbatard branch to provide the underlying infrastructure for windows support. The combination of these libraries allows us to have a common USB library interface on Linux 32/64, MacOS 32/64 and Windows 32/64. The libusb-pbatard branch interfaces with WinUSB, so it's all userspace, which means we don't have to develop a kernel driver and simplifies our development cycle...

On top of this sits a set of C-libraries that provide a more abstract, human understandable interface to our USB wigit, thereby hiding the low level protocols. This is analogous to your windows UD libraries. However, since our libraries sit on top of a platform independent USB library, we can have the same abstract libraries work on all OS's... This is all implemented in C, as we provide our libraries to 3rd parties for integration into their applications, which include Linux/mac GCC based apps, MS Visual Studio apps, matlab, and many others. DLLs/SOs/DYLIBs are provided. So long as the 3rd party can load up a dynamic library, they can access all our hardware, on all platforms, using the same library interface...

On top of the abstract C interfaces, we use SWIG to auto-generate other language bindings, such as JNI bindings, python bindings, and anything else that SWIG supports. This is pretty handy because SWIG does 97% of the tedious, time-consuming and error prone grunt work. For some things we go in after the fact and provide even further refined interfaces, but the nice thing is that any number of language bindings can all be automatically generated at the same time.

The particular type of hardware in the loop testing we're trying to do requires that we run on Mac/Windows/Linux, 32/64, so we have interest in full cross platform support with API semantics common across all OS variants.

I'm not trying to convince you to do anything in particular, but rather highlighting various techniques that a company could utilize to get full cross platform support, with abstract APIs, and many language bindings, all with one piece of infrastructure....


Food for thought...


Thanks so much,
-d

#5 Iandol

Iandol
  • Members
  • 46 posts

Posted 11 February 2011 - 08:52 AM

Can I just add a big +1 for a unified API. :) Currently I'm having to think about supporting Windows, and not having a unified API is a real pain. As a slight aside, I see Measurement Computing are now providing an open-source cross-platform unified API (DAQFlex) for their OEM USB boards, and I suspect there must be a market out there for DAQ users who don't want to rewrite their software if they need to change platform...

#6 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 11 February 2011 - 10:11 AM

We are moving that general direction on most everything. The first thing you will likely see is an improved LJSocket working on Win/Mac/Linux. Then likely LJFuse. Making the exodriver more windows friendly, or something like that, is also on the list. One current option people have used for awhile is platform independent TCP code talking to the UE9. Another decent option, is that if you are using raw writes and raw reads and the protocol from Section 5 of the U3/U6/UE9 User's Guide, you just have to have some code to handle whether those are passed with the Exodriver or UD driver. Also, if you don't want to pass Section 5 low-level commands you can pass modbus commands this way, even over USB.

#7 pmcintosh

pmcintosh
  • Members
  • 26 posts

Posted 18 August 2011 - 03:02 AM

I'll add another vote for cross platofrm API. I headed down the track of a crossplatform solution with Qt/MingW - I have everything working under Windows fine without any Windows dependency, then decided just now to do the Linux part. In theory with Qt the same code should work... [codebox] QLibrary ljsharedlib("labjackud"); ljsharedlib.load(); //If successfully loaded, get the address of the functions. if (ljsharedlib.isLoaded()) { m_pListAll = (tListAll)ljsharedlib.resolve("ListAll"); m_pOpenLabJack = (tOpenLabJack)ljsharedlib.resolve("OpenLabJack"); m_pAddRequest = (tAddRequest)ljsharedlib.resolve("AddRequest"); m_pGo = (tGo)ljsharedlib.resolve("Go"); ... [/codebox] However as the API is so different, I'll just have to leave the Linux part as it is too much effort. Cheers, Paul

#8 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 18 August 2011 - 08:51 AM

Yes the UD driver is abstracted from the low-level protocol, while the options for other operating systems are much less abstracted and more follow how the hardware works directly. The new multi-platform driver (LJM) is very close. It supports Windows, Mac, and Linux now, but we plan to support Android and Windows CE and whatever else we can. You could probably try it in a couple weeks if interested. It uses a simple interface based around Modbus. The other option is LJSocket. This is beta at the moment, but quite useable and you can download it. You also talk Modbus through LJSocket, so it should be pretty easy to move between LJSocket and LJM.

#9 mhopeng

mhopeng
  • Members
  • 7 posts

Posted 20 August 2012 - 06:12 AM

I'd also like to see Exodriver support on Windows for cross-platform development. LJFuse is a very cool idea, but it requires a working installation of FUSE. LJSocket is also cool, but requires more complex user programming and socket support. Either replacing the libusb calls with Windows USB calls, or using libusb on Windows *sounds* easy enough :) Obviously I do not know what I'm talking about, otherwise I would do it myself...

#10 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 20 August 2012 - 03:10 PM

Currently there are no plans for Exodriver Windows support. You can try the LJM driver which provides a cross-platform interface:

http://labjack.com/support/ljm

Also, LabJackPython provides a cross-platform interface.

I will point out that for operating systems that the Exodriver does not support, the source code is available on github if people want to port it. Libusb 1.0.9 added Windows support I believe.

#11 Iandol

Iandol
  • Members
  • 46 posts

Posted 22 August 2012 - 02:10 AM

Hi, could you summarise what, if any, are the downsides are to using the LJModbus interface. From my point of view the speed of command-response would be my major concern, but it would be interesting to know whether you are aiming to try to unify your drivers behind this modbus driver going forward. For example will your new devices be supported by the exodriver, or only modbus? Reading briefly through the header file the interface is slightly more verbose than the exodriver. Great to see T7 support in there too!

#12 LabJack Support

LabJack Support
  • Admin
  • 8677 posts

Posted 22 August 2012 - 02:07 PM

The LJM (previously LJModbus) driver is the unified driver/interface for all supported operating systems and LabJack devices. New LabJack devices will use the Modbus protocol and no low-level functions. The LJM driver uses the Exodriver for USB communications, so yes the Exodriver will support new devices though we recommend using the LJM interface as opposed to the Exodriver directly. If you want to make your code more cross-platform we suggest switching over to the LJM interface. As for speed, UD devices (UE9/U3/U6) command/response may be a little slower with some analog related I/O (when you read a float value), though it is not substantial and may not even be noticeable. We need to do some speed tests to give a better answer. Also, since the driver is still in alpha there are some features, such as streaming, which are not implemented yet. They will be there in later versions.


0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users