回复： Re: Fatal Internal Error : image.cpp line 12727

[Ashleysz]

Hello ,

I meet the same problem ,please see below picture,when I run the program as first picture,the error will be popuped,when I run the program as second picture,no error.

[JÞB]

Since the  original discussion is over 9 years old.  I started a new thread for you.   Next time, please watch out for the date on the post you are replying to. 

What version of LabVIEW are you using? Could you post a snippet of the code?  It is hard to debug a picture 

[Ashleysz]

Hello ,

I used labview 2015,and the code included below.

[zou]

You are making tons of dll calls.

Most likely, one of those call configured wrong.

Access RX ID is just "最后一根稻草".

[zou]

The last dll call (xlReceive) has a very very complicated input data type.

The last parameter is an pointer to an array of structure of many structures/unions/...

You made it too simple.

The 2nd parameter is a pointer to an unsigned int, should be U32, not U16.

It would be a lot easier if you create a wrapper dll in C, use simple data type for LabVIEW.

[rolfk]

Lots of inaccurate datatypes in your Call Library Node configuration. And then you should not wonder if you get strange results or crashes!

With misconfigured parameters you create easily so called buffer overrun errors that will alter other information stored in memory. And this other information could be a LabVIEW data structure or some data of your program and then you get these kind of strange errors, as you corrupted memory.

While I have no intention to go through this whole code and make a review, a few things that showed up immediately are:

- xlOpenDriver() (and most other xl APIs) returns an XLstatus which is defined as short, which is a 16 bit signed integer.

- Don't create a NULL terminated C string yourself for the second parameter of xlOpenport(), but configure it instead as a String, passed as a C String Pointer, no need to define a minimum size as this is an input buffer to the function, not a buffer where the function wants to write something into.

- The 3rd parameter to xlCanTransmit() is a unsigned int passed by reference, so a 32 bit signed integer, Pointer to Value

- The 2nd parameter to xlGetReceiveQueueLevel() is an int passed by reference so a 32 bit signed integer, Pointer to Value

Who did tell you that an int is a 16 bit integer? That was true in 1985 with DOS and MacOS, but since Windows 95, an int really is always 32 bit, unless you work with some low level embedded controllers.

And of course there is the big, ugly and nasty xlReceive() which I highly suspect to be the entire culprit for your "strange" error, just as George already hinted at.

Again the obligatory int configured as 16 bit instead of 32 bit integer, and the last parameter is supposed to be an array of XLevent structures, which is basically the same as the structure passed to the xlCanTransmit.

Also the whole shenigan you do to convert the 64 bit TX CAN ID into the individual bytes makes not very much sense. First you really only use the lower significant 4 bytes of that number so why even have it as a 64 bit integer. Second, because of the Typecast the data gets byte swapped, which is why you have to index the byte array from the end instead of the beginning. However if you start to do such strange things you may learn them and use them anywhere even on platforms that use Big Endian such as the RIO hardware that is based on a Power PC CPU.

Better would be to use the Flatten to String function with a String to Byte Array, and select the Little Endian byte stream format. Then it will always work right for this case.

[Ashleysz]

Thanks for your reply and I don't know what should say.

[TroyK]

Maybe try the vxlapi.dll wrappers here that have been in use for over 5 years...

Vector XL Driver - LabVIEW wrappers