LabVIEW
HDLC FastCom Card
Harold Timmis wrote:
Has anoyone used the FastCOM FSCC-PCI for HDLC I am trying to figure out if the sample code for the dll is a driver for the card or is it where you build your vi? if it is where you build your vi(application for the card to use); is there a way you can write it in G or do i have to write it in C?
Since it is a PCI card there basically has to be some kernel device driver to make that card usable in any modern OS. And accessing a kernel device driver does need some low level API calls in user mode that are rather unconvinient to be done in LabVIEW directly. So this means there is usually also a user space API DLL to access that kernel driver. On top of this API you then can use LabVIEW to call into the user space DLL or you might have to create another intermediate C DLL to translate the user space DLL API into an interface that is more suitable for LabVIEW. This intermediate DLL may be necessary if the API makes use of things such as callbacks or complicated structure types with embedded variable sized array or string pointers.
I do not know your card nor what you mean with the words "sample code for the dll". Is it sample code for how to use the provided user space API DLL or is it code that shows how to write such a user space API DLL? From a professional solution I would expect the first, a hobbyist solution might provide the second and that would be not a good thing to use for an industrial grade applicaton unless you do have quite a bit of experience in dealing with C code and accessing kernel mode APIs.
Rolf Kalbermatter
Hi BrianK,
@BrianK75 wrote:
I know that this a seriously old thread but I am using several FastCom FSCC/4-PCIe cards and trying to find drivers for these.
https://fastcomproducts.com/products/fastcom-fscc4-pcie/
Only a few of the LabVIEW vis seem to work in this package. The working ones used VISA vis.
When your card provides 4 COM ports (via its own driver) then using VISA seems like a natural choice! Why don't you stick with this solution?
@BrianK75 wrote:
The non working vis all had one thing in common, they all used a .dll file from LabVIEW 2011.
I changed the directory to point to the .dll file in the 2019 and 2020 versions I am currently using (different computers) and no luck. It seems that the dll is a 32 bit and I am running 64 bit LabVIEW. Searching through threads concerning 32-64 seems like this will not work unless I install a 32 version.
A 64bit executable will only support 64bit-DLLs. A 32bit executable requires 32bit-DLLs. Simple rule, not just for LabVIEW, but for all (Windows) software…
Solution: install 32bit LabVIEW when you NEED to use those 32bit DLLs. Is there any reason to use the 64bit version of LabVIEW?
From a quick look at the Git project, I would guess that there are two APIs here. One is the normal COMM Windows API that can be used from within LabVIEW through VISA for async operation of the card. But that would mean that you can only do normal RS-422/485 communication. If you want to use the fast HDLC and similar protocol support it seems one needs to use the DLL interface directly, which is a learning curve for sure even if you do not have to create the DLL interface anymore (as it seems this library already provides).
That GIT project seems to contain the entire source even for the kernel driver part (which is required for any hardware that is mounted in the PCI/PCIe or other similar interfaces including Thunderbolt etc.).
The kernel drivers itself seem to be already provided for 32-bit and 64-bit so that part would not need to be recompiled. Also this part is independent of the bitness of the application you want to use, but only depends on the bitness of the OS you want to install it in. To access a kernel device driver you then need a user space driver too in the form of a DLL, and this part needs to be compiled in the bitness of the application you want to use.
Your LabVIEW driver project only seems to contain the 32-bit version of that DLL and the GIT project only contains the sources but not the build products. However if you go to the manufacturer page they have links to some download packages: https://github.com/commtech/fscc-windows/releases/tag/v2.7.8
You want to download the fscc-windows-2.7.8.zip package and in there you have the binary driver installers for the 32 bit and 64 bit drivers. While you need to install the driver with the bitness that matches your OS, you will need the fscc.dll from the folder with the bitness your LabVIEW has.
Now one big warning here: I have not looked at the LabVIEW VIs and can not guarantee that this will simply work. There are many possible differences when calling a 32-bit or 64-bit DLL and depending on how the DLL interface is modeled and the LabVIEW library written, it can be very incompatible. And there is no safety net in the form of a LabVIEW wizard or Windows crash prevention magicien here, if things don't match you can have effects from no apparent problem but hidden and almost impossible to debug bugs, delayed crashes long after you called the DLL functions, to an immediate crash that either takes your app more or less brutally down, with or without debug information, or even a "very beloved" blue screen of death. So if you do not feel comfortable with C programming, C datatypes, debugging in a low level debugger and lots of edit, run, crash cycles, you may be better of to simply install the 32-bit version of LabVIEW and use your existing driver.
