Good and robus for the purpose, but there is a room for improvement
ATTENTION! length limitation for this post in unfair!
I spend good time trying to write a detailed review, so this is very frustrating. Who will write reviews for you if you do such nonsense? Who would like to waste time?
Please fix it.
We happen to have some good applications for miniLAB 1008. Even though we have to think hard to fit all the required functionality in the limited set of miniLAB channels, with only 24 digital I/O channels plus 4 individually addressed digital I/O channels being out bottleneck, the result is a very compact, light-weight and low-cost design used in very mission-critical and touch applications, commutating up to 15 kV very quickly and causing tremendous induction currents, which is used for very rigorous testing of electronic chips.
Our experience shows that the unit is also tough and reliable enough: despite of such electromagnetically tough environment, out hardware people burned out only one analog output port so far, which is actually a good result; and the damaged unit is still used in R&D. One of the problems we had to address is somewhat limited performance in computer-paced mode: we could get 8 ms of latency on the digital output port; and the documentation maintains that the round-trip period for computer-paced analog readout is about 50 ms. However, it all depends on the application; so we seem to perfectly fit in our requirements.
One other problem is relatively high current consumption from USB. Typically, we have to tether two more USB data acquisition devices to the USB hub of the same PC host, and at first the system reported USB malfunction. We had to redistribute USB cables between hubs and reduce electric drain from digital outputs to reduce the load on USB. I don't think this is a big problem, but the developers of applications probably need to keep it in mind. Maybe, optional external power source for miniLAB could be a viable option, hard to say.
One apparent problem is the lack of operation by hardware interrupt, [shortened...]
Minimal software for Windows, unfortunately, requires installation, but then it works out of box. I say "unfortunately", because the control via USB bus, without inversion of controls (hardware interrupts mentioned above) does not requires installation of any drivers. Yet, manufacturers want the customers to install their software, and decent engineers on customer's side always want to avoid any installations, by reasons which should be apparent.
And indeed, MCC DAQ software does not really need installation. All what is needed is just two DLLs: cbw32.dll and cbw64.dll, so the Windows solution support just two most used instruction-set architectures: x86, 32-bit, and x86-64 (or AMD64), 64-bit, but probably not original Intel IE64 (Itanium). As to the .NET, it requires one more file, a .NET assembly mccdaq.dll, which actually loads cbw32.dll or cbw64.dll, depending on detected "bitness" of the current process. The assembly itself is compiled to the target platform "Any CPU", which allows using it in the platform-agnostic manner, despite the fact that native "cbw" DLLs are compiled to two concrete instruction-set architectures. The assembly uses pretty smart method of binding of native API, by dynamically loading one of native DLLs. So far so good.
Is it good or not? Well, it works and reliable enough but... naive. Presently, even though we use .NET for controls, we don't use company-supplied mccdaq.dll, but use only native cbw32.dll and cbw64.dll and bind them with .NET and install in our products. I wish you had the source code of the two native DLLs, to use the MCC units better.
The software we got is enough robust, don't give us many problems but... quite naive. As it very typically observed on the software developed by hardware companies, people don't quite understand the platforms and OS. First surprise I found in mccdaq.dll is the use of .NET library System.Windows.Forms. Why? How this purely UI library of some limited use could sneak in the pure hardware unit? The answer is very simple: it is only used to show one dialog box in case of only one error. This is dreadful. It's quite obvious that such things should never be used. All .NET programming requires is throwing exceptions, and never anything else. Even returning of error status by each API is totally pointless. If it is done in C, this is quite explainable, but for .NET methods, which wrap around native functions, this is simply unacceptable and only bloats the CLI code and create small but totally pointless hassles for application developers.
So, we got rid of original mccdaq.dll and installation. The installation is still needed for at least one computer, to run the utility called InstaCal, inscal32.exe. This utility is simply faulty. Try to modify the board ID – it will show exception, but the ID will be successfully changed. In fact, if more than one unit is used, setting up this ID stores it in the unit's power-independent memory, and is this is the only reason to use this utility. That brings us to next section.
Now, two other problems are more seriously. I found that the API fails when a working directory differs from the "executable directory", where cbw32.dll and cbw64.dll and a configuration files are put. It happens only on the first call to API. It means that initialization of the API happens on the load on call basis, and then CFG file is not found. I had to work around this problem by calculating out the location of executing assembly and temporary setting work (current) directory of an application to this location, only during the very first API call. Despite easy work-around, this is a really serious problem. (Maybe, it does not exist when the software is formally installed, but who cares? Redundant installation is evil; a bug is a bug.) It should be understood that the working directory is something which cannot be guarantee. It actually depends on the action of the final user who launches the application. It can be started from absolutely any directory, which becomes a working directory. Moreover, there are many cases when working directory has to be different from executable directory. Again, this is easy to work-around (after scratching one's head though), but this is not even a bug, this is illiteracy.
Another considerable problem is this: fast repetition of some commands causes failure. For sure, it happens when "flash LED" command is issued two times in a row without a delay. I do understand why it can happen, but it certainly requires a fix. I reported this problem during my call to customer service, which will be discussed below.
Unfortunately, I unpacked several units and found that factory-set ID values are different and random. This creates a real hassle.
[shortened...] ID should preset at some default values, which should be documented.
Documentation looks detailed enough, but not perfectly structured. Main disappointment from the documentation is the lack of proper cross-references between different documents. At the same time, this cross reference would be extremely useful. As it is, the documentation could not be characterized as satisfactory. As all of the MCC DAQ units are served by a single unified software project (which is, again, is a very good thing), the relationships between API methods and particular channels of particular devices becomes pretty tricky and not apparent for the person who reads both software documentation, and hardware documentation specific to miniLAB 1008. For example, when I found that I could use the individually configured I/O ports marked as DIO0 to DIO3 in the body of the unit and hardware documentation, it was not clear how to address them through the software port indexing system, which itself is not quite trivial. My first guess that I should address then via AUX port index in software turned to be correct, but I had to confirm it using a call to customer support. Some other delicate moments are not clearly documented. For example, I had to think how to configure 4-bit ports CL and CH, when the overlapping 8-bit port C can also be configured. CL and C has the same index in the "port type" indexing system, configuring C after configuring CL should somewhat unexpectedly override CH configuration. After looking thoroughly at the values if the indexes and some thinking, I was able to configure ports correctly, but such things should be clear in documentation, as this is the part where a naive user could easily make a mistake.
In this poor collaboration between hardware and software parts of documentation, I can see the usual lack of understanding between hardware and software specialists. I hope this part can be improved. And, after my experience with customer support, I'm nearly sure that I would be able to resolve all such issues. This brings us to the Customer Support section.
I had to address customer support only once, with my doubt on addressing or AUX ports as I described above. [shortened...] Overall impression from customer support was good.
The unit is very does not offer tremendous flexibility and performance, but is very good for the purpose and the price, if the features fit required spec. It is reliable enough and easy to get started with. For certain class of application where this unit is suitable, it will be a great find. There is a room for improvements and some fixed, but all those problems are minor and can be worked around in some reliable ways.
- Job Title: Software Architect
- Industry: Electronics
- Application: Static electic discharge, destructive testing of electronic chips