CIN with simplest array?

[ACiDuser]

#include "extcode.h"


/* Typedefs */
    int32 Array1[11] = {6, 4, 23, 44, 12, 32, 11, 21, 34, 33, 54};
   
typedef struct {
    int32 dimSize;
    int32 Numeric[1];
    } TD1;
typedef TD1 **TD1Hdl;
//TD1Hdl Array=NULL;
MgErr CINRun(TD1Hdl Array);

MgErr CINRun(TD1Hdl Array)
{

     int32 i= 11;

   MgErr err = NumericArrayResize(iL, 1, (UHandle*)&Array, i);
    (*Array)->dimSize = i;
    for (i=10; i=0; i--) {
        (*Array)->Numeric[i]=Array1[i];
  }


    if (err)
       return err;

    return noErr;
}

from now it returns Zeros to array, where might be the problem?

[ACiDuser]

Thank you very much!!! It works fine! There was a dummy mistake in a FOR loop 🙂
Thank's for fast and helpful answers!

[rolfk]

---

@bi wrote:
Thank you very much!!! It works fine! There was a dummy mistake in a FOR loop 🙂
Thank's for fast and helpful answers!

---

Indeed 🙂

For those that wonder what he refers to:

Change
    for (i=10; i=0; i--) {


into
  for (i=10; i>=0; i--) {

Rolf Kalbermatter


Message Edited by rolfk on 03-12-2008 08:47 AM

[ACiDuser]

Hello! You advised me to use MoveBlock function.. but it doesnt work. In my C source code I have mmaped memory using function "mmap" it returns a pointer of type (unsigned char *). Then I set char (or uChar) (tried both): char vertiba = ptr_to_pci_mem[1] And I want see data on indicator. Tried different types of indicators, even string indicator. Tried using MoveBlock function and nothing. Please help me with this question, where am I wrong? what should be done for realizing this task? #Code: ...... ...... MgErr CINRun(uChar String); MgErr CINRun(uChar String) { ...... ...... unsigned char *ptr_to_pci_mem; #define PCI_MEM_LEN 2097152 ptr_to_pci_mem = mmap(NULL, PCI_MEM_LEN, PROT_READ|PROT_WRITE, MAP_SHARED, fd, (off_t)pci_mem_addr); MoveBlock(&ptr_to_pci_mem[1], &String, 2); ...... ...... Waiting for your wise advices and answers.

[ACiDuser]

I removed this: int main (int argc, char *argv[]) { and now cannot build CIN it says undefined symbols. And I've edited the Makefile and added libraries ( -lz -lpci ) everywhere. And it's compiling not. And Don't know why in Ubuntu Labview do not show messages in gcc terminal. Something might be wrong with labview working with ubuntu?

[rolfk]

---

@bi wrote:
Hello! You advised me to use MoveBlock function.. but it doesnt work. In my C source code I have mmaped memory using function "mmap" it returns a pointer of type (unsigned char *). Then I set char (or uChar) (tried both): char vertiba = ptr_to_pci_mem[1] And I want see data on indicator. Tried different types of indicators, even string indicator. Tried using MoveBlock function and nothing. Please help me with this question, where am I wrong? what should be done for realizing this task? #Code: ...... ......

MgErr CINRun(uChar String);
MgErr CINRun(uChar String)
{
...... ...... unsigned char *ptr_to_pci_mem;
#define PCI_MEM_LEN 2097152
ptr_to_pci_mem = mmap(NULL, PCI_MEM_LEN, PROT_READ|PROT_WRITE, MAP_SHARED, fd, (off_t)pci_mem_addr); MoveBlock(&ptr_to_pci_mem[1], &String, 2);

...... ......

Waiting for your wise advices and answers.

---

Could it be that uChar is not a string at all but really just a single character???

You probably never created that prototype from the CIN node otherwise you wouldn't have gotten this. Here uchar would be passed by value, so the caller will never see its changed value, even if you just did want to return a single byte.

What you will want to do is passing a LabVIEW byte array handle instead, resizing it in your CIN with NumercArrayResize() and then filling the data with MoveBlock into it. What you do here is completely wrong in several ways.

From this example it would appear to me that you do not really have much experience in C programming. Please be adviced that CIN programming has its own extra complexities and therefore is completely unsuited to learn the basics of C programming with.

Also I'm sure you heard that already but I repeat it here for completeness: CINs are a legacy technology in LabVIEW. They were created at a time were most of the LabVIEW platforms did have serious fundamental problems to interface with plattform shared libraries/DLLs. Since the demise of LabVIEW support for MacOS Classic, Win 3.1, and HPUX this is not a problem anymore and the shared library/DLL interfacing through the Call Library Node is functionally equivalent but has the extra advantage that you can do it all in the development tools for your actual platform. If you can create shared libraries and know the basics of C you are all setup. With CINs you use a proprietary technology only National Instruments alone understands all the technical details about, and limit yourself to the support that NI can give you. CIN tools repeatedly was broken in recent LabVIEW releases in one way or the other and the priority to fix them was always way done the list.

To say that CIN support will and is going to fade away slowly in LabVIEW IMHO a safe statement. I predict that at some point the CIN tools will not be delivered with LabVIEW anymore. You probably will be able to download them from somewhere for the platforms that have had them already but it is likely that they will not be adapted to support new binary platforms such as LabVIEW for Win 64Bit or whatever else will be coming out.

And your second post is a bit strange. To see that above example did not work you obviously must have been able to compile and link it. So if it suddenly does not work, try to reverse the things you did one by one until you get a working solution again. It's the only way to learn things and from the little information you give the only advise I can give.

Rolf Kalbermatter

Message Edited by rolfk on 03-14-2008 08:30 AM

[ACiDuser]

Hello, so if it was a bit strange than I can explain better: so I tested CIN - created CIN block wired with numeric indicator, and created .c file, there I've added parameter *Numeric = 32. And launched this VI. Works - I see in the numeric indicator - 32. And then I've tried to do the same with my C program for PCIE - there C code does it's own and I've added only this parameter *numeric = 32. If it worked I should see the same - 32 on numeric indicator. But there was nothing. So I modified my C code for creating a File and writing there. (modified C code not CIN functions) for CIN functions again there was only returning *Numeric = 32. So It compiles, and when I run it - nothing happens - no value to numeric terminal AND - no output file with data - so It means that whole C code not working. (but it was expected working, cause I've tested Code compiling with gcc and It build applications and works fine). And than my collegue told that I shouldn't use " int main (int argc, char *argv[]) { " And that " CINRun" already is main function. And I removed this " int main ... { " after that I can't compile my code - see messages undefined symbols. And I cannot swith off string by string because without them program will not work. So It means that compiler don't see Libraries (that I pass when compiling with gcc -o pcie pcie.c -Lz -Lpci ) and I've modified Makefile adding them to LDFlags and CFLags - like was explained in Manual. Still not compiling. I think now I explained clear about my problem? And.. in the Terminal I see information only when compiling CIN. And when launched CIN with labview no information in terminal - but there it's expected to see printf calls that are in my C code. Can I fix this ? or should I change to other Linux? Which one? " If you can create shared libraries and know the basics of C you are all setup." With this do you mean I should created 2 Call Library nodes and launch that libraries which I link compiling with gcc and that are situated in /usr/lib ? (2 libraries Libz and Libpci) Or you suggest - to compile my code as Library and then pass It to Call Library Node ? Should I use this " int main (int argc, char *argv[]) { " Or code must work without this function? Note: this code compiles with GCC perfect (even with " int main (int argc, char *argv[]) { " ) but In CIN inside this "main" nothing works, and without it it's not compiling.

[ACiDuser]

And forgot about one more questiong: If my C program creates a file with output log, and I modify it for CIN (and for LabView there will be only returning Numeric = 32) will this C code doing his work? or I should modify the Whole C code - using only CIN functions? (for writing file for example).

[rolfk]

---

@bi wrote:
And forgot about one more questiong: If my C program creates a file with output log, and I modify it for CIN (and for LabView there will be only returning Numeric = 32) will this C code doing his work? or I should modify the Whole C code - using only CIN functions? (for writing file for example).

---

Sorry your two previous messages are lengthy but absolutley not clear to me. An attachment with the C code and VI would be probably worth about 1000 words of explanation.

All I can make up from your explanation is that you seem to have fundamentel problems about understanding how to use C in general, and about the C toolchain build process under Linux more specifically. As said, CIN development is one of the worst suited areas to learn about these things.

Rolf Kalbermatter

Message Edited by rolfk on 03-14-2008 02:40 PM

[ACiDuser]

Ok... about compiling CIN, I've read on forums and made linkage with "ldconfig -s libpci.so libpci.so.2" and It begun compiling.
So Rolf.K., it wasn't connected with my fundamental problems with C. But still CIN not working when loaded in VI. Maybe those Libraries are called only when compiling CIN (because in Makefile they are present), and when Launching VI with CIN those Libraries are not loaded and thats why CIN not working?
1) In other words If my CIN uses other shared libraries that are used during compilation of a CIN, should I load them when launching VI with this CIN ?

Then I tried building new CIN that simply returns *Numeric = 32. and inside code with C functions it makes a file "log.txt" and writes this value also there.
On this point Labview crashes.

program code:
===================
#include "extcode.h"
#include "hosttype.h"

MgErr CINRun(int32 Numeric);

MgErr CINRun(int32 Numeric)
    {
Numeric = 32;
FILE *sp;
sp=fopen("log.txt","w");
    fputc(Numeric,sp);
fclose(sp);
    return noErr;
}
===================
2) Does it mean that I can't create file simply using standard C functions? Should I use only LabView CIN functions for creating and writing into file?
===================
I read in Manual "Using External Code" that Call library nodes are more easy to use. But what about being Thread Safe?
• The code is thread safe when it does not access any hardware. In other words, the code does not contain register-level programming.
• The code is thread safe when it does not make any calls to any functions, shared libraries, or drivers that are not thread safe.
• The code is thread safe when it uses semaphores or mutexes to protect access to global resources.
3) Does it mean that I can use Thread safe Call Library node only for calculating some kind of  "2 * 2"  ?
4) What is "semaphores or mutexes" ?
===================
Rolf.K wrote:
"I predict that at some point the CIN tools will not be delivered with LabVIEW anymore."
And can I make everything, that allows me CIN, with Call Library Nodes? (I'm interested in accessing hardware and funtions)

As for previous posts still didn't get answers on following questions:

5) Do you suggest - to compile my code as Library .so and then pass It to Call Library Node ?
6) Will I be able with this Library - to access hardware through PCIE, to write Data from PCIE board memory to file and to fill arrays with this data ? (as the program does)
7) Can I Launch those Libraries pcie.so.2 libz.so (which are used during compilation) with LabView into memory - that they will be launched only when my VI works ?

As for program code and VI attached below:


Message Edited by bI on 03-17-2008 07:10 AM