[Sneap] Group3

[Philip Banks]

On 17/07/2008 12:33:08 AM Bret Carlin wrote:

>We just upgraded one of our control computer's hardware.  The Group3
>memory driver we had been using will not work on this machine.  We
>downloaded a new driver:
>
>http://www.group3technology.com/dlarea/docs/G3_LC_Driver.ZIP
>
>and it recognizes the loop controller.  The Group3 vi's we were using do
>not work with this driver.  Based on our searching, we need newer vi's
>that are in a g3c.llb library.  We have been unable to find a download
>location for this library.  Does anyone using Group3 with Labview have
>any ideas on where to get this library?

Having just been through this process recently here at GNS Science I 
hopefully can help a little.  You need to contact Group 3 directly to get 
this - as of v4.7 of their LabView library they have moved the memory 
handling functions into a DLL. It is pretty much a drop in update and 
brings a few fixes to issues like faster computers overloading the loop 
controller with requests. They are very amenable to email and seem quite 
happy to send you the library which is up to v5.0 as far as I know. 

We have found two curls with it :-

First if you are like us and wish to put the dll and llb directly into a 
CVS system, so that the whole software system can be rolled out of CVS 
onto a freshly commissioned machine with just LabView installed, then you 
do have to do a little editing of the Call Node references to reflect the 
new position of the dll in your CVS structure. By default Group 3 want it 
to be a user libary stored in something like 'C:\Program Files\National 
Instruments\LabVIEW 6.1\user.lib\Group3 Control' (substitue the 
appropriate version of LabView you are running in the directory path). 
This takes five minutes to do once you know where to edit but it is 
something you will have to remember to do every time you update the 
library in the future.

Second our experience has been that the driver/library is very hostile to 
multi-core processors. This is likely something related to the way we are 
using GOOP to explicitly paralellise our code by instancing vis. The 
symptom we get is a hard lock of the computer requiring a hardware reset 
or power off to escape. This makes diagnosing the fault tricky. So far the 
only solution we have is to roll back from any multi-core Core Duo 
processor and go to a Pentium 4 chip. Try finding those, or indeed any 
single core processor, new these days to replace old hardware! We even had 
to turn off hyperthreading as this tickled the fault as well.

I'd be very interested in hearing if anyone else suffers from the 
multi-core issues we have in the hopes of getting a better handle on what 
is going on. Especially as Group 3 assure us that they have their system 
running just fine on a multi-core system.

Philip

Notice: This email and any attachments are confidential. If received in error please destroy and immediately notify us. Do not copy or disclose the contents.