Jump to content

stevea1973

Members
  • Posts

    5
  • Joined

  • Last visited

stevea1973's Achievements

Newbie

Newbie (1/14)

0

Reputation

  1. One of the reasons that something like this might be useful is if you can do something like I have done before: Create a thread Set the affinity of thread for one cpu bump the thread priority to realtime This stops inturrupts (e.g. mouse, keyboard) and runs the thread pretty much to the exclusion of all else on that cpu (to be honest, it has been a while, I may have done it via a second process, and had some IPC). You have to be careful to only do this with a multi-processor machine and also to ensure that you don't realtime more than n-1 CPUs as otherwise the OS can't get in to process anything. I never did anything more than p-o-c with it, we decided not to bother in the end.
  2. QUOTE (altarama @ Apr 30 2009, 12:15 PM) From what I have seen you should use an Invoke node and get the ToString() method called. I guess labview will take care of Unicode or UTF-8/32 to your code page conversion.
  3. QUOTE (Umit Uzun @ Apr 29 2009, 09:29 PM) Just declare the entry in the node as a string and Labview will pass a ptr to a string (char * or wchar* depending on your environment I guess). All pointers are just pointers, a char* is the same as a int* etc. It's just in the dll it will treat it differently.
  4. QUOTE (greatwall @ Apr 5 2009, 08:39 PM) There are a couple of issues really. The statement char **ch declares a pointer to a pointer, so it is wanting to manipulate the reference you have to the string, I expect labview would have a few issues with that as it may cause loss of data because you are losing a reference to whatever that wire held. I really don't know how it would interact with labview, but I'd guess it might not be nice. The return of (*ch) is pointless, you have already modified the callers data in the line (*ch = pstr;) Now probably the biggest problem. char *pstr = "this is string!"; declares a pointer that (potentially, compiler dependant) points into the data section of the DLL, this will possibly be marked read only by the OS and any code down the line that tries to alter that value would fail if so with an access violation. It is far too compiler dependant to use. It is probably this last factor that is causing issues, you would have to allocate a new chunk of memory and initialise it with the value. Additionally if the DLL moves out of memory then your memory reference would then be invalid.
  5. QUOTE (Joshuatronics @ Mar 7 2009, 02:08 AM) Here's a question and also partly an answer to your query. Your structure will almost certainly be: typedef struct { BYTE ff; /* frame format: 0 = basic CAN, 1 = extended CAN */ BYTE rtr; /* 0 = normal frame, 1 = remote frame */ BYTE dlc; /* data length 0..8 */ [bYTE OF PADDING] DWORD id; /* telegram ID */ BYTE data[8]; /* data */ [3 BYTES OF PADDING] sTS timestamp; /* time stamp*/ }sPCCanMsg, *psPCCanMsg; Now in your diagram you don't have the padding, but you also don't define id as U32. Bearing in mind this, I can't see how it will now be working (unless you have fixed this), unless the structure is packed in the header file. Does labview do automatic guessing of padding (since you can byte align or pack depending on choice) and how can you control this.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.