I need a list of common m_script functions that MathScript does not support

[Worried_of_Bexley]

As a newbie to MathScript but not LabVIEW I eagerly plugged in a Mat*** m_file and immediatly ran into the lack of an "fseek"" function. I'll rewrite the m_file to get around it. It would be useful however if someone could point me to a list of functions that are not in MathScript but which are in the base version of Mat***. Even a partial list would help. I have read the "Complete LabVIEW 8.20 MathScript Function List" (truely!) and note that (a) "fseek" is not there and (b) "fopen", "fread" etc are not supported in the LabVIEW Run-Time Engine (could someone explain why?). I'm using LabVIEW 8.0 Professional under Windows XP until my copy of 8.2 arrives.

Regards,

Worried_of_Bexley

[SNN]

Hi. I have LabVIEW 8.20 and can confirm that fopen, fread, fwrite, and fclose are now supported. I have not tested these. There is however no 'fseek' command.

[Worried_of_Bexley]

Thank you SNN

Dare I hope that fopen, fread, fwrite and fclose are now supported for stand alone applications constructed using the Application Builder and not just supported when you are in the usual LabVIEW environment? fseek is particularly useful to parse binary files constructed by applications written using other languages that support structures.

Regards,

Worried of Bexley.

[GrantM]

Hello,

Unfortunately, the commands fopen, fread, fwrite, and fclose are NOT supported in the Application Builder.  They are only supported in a development version of LabVIEW.  For a list of all such functions, see the LabVIEW help topic "MathScript Functions Not Supported in the LabVIEW Run-Time Engine."  In LabVIEW 8.2, the "eval" command should also be part of the list, but it was inadvertently left off.  The reason these commands are not supported is that they rely on the search path.  A built application may be deployed on a different machine from which it was built.  Consequently, the directory hierarchy may be completely different and any search path settings would most likely be incorrect.  How do you intend to use the functions?  Can you specify an absolute path to a file?  This would require that the file be in the same place on every machine to which the built application is deployed.  Would a relative path work instead where it is relative to the location where the built application is installed?  We can modify the file commands to work as such in a future version of LabVIEW.  Would this be useful to you?  In the meantime, you can use LabVIEW's file operation VIs to read and write to a file and pass data into the MathScript node.

We do not currently maintain a list of unsupported functions.  However, I will take any suggestions you have for functions you'd like to use as well as how you are using them (I see you were looking for "fseek").  We will consider implementing them in a future version of MathScript.

Grant M.
Staff Software Engineer | LabVIEW Math & Signal Processing | National Instruments

[Worried_of_Bexley]

Dear GrantM,

Thank you for your detailed and clear explanation of absolute file paths in MathScript. As you can probably tell Mat*** is not my usual language (C and LabVIEW are what I usually use) and I am quite unfamiliar with common restrictions of m_files and their search paths. I would find it very useful to be able to use paths relative to the install path.  As you correctly point out LabVIEW  vi's can be used to pass script data to MathScript nodes. Being a fundamentally lazy person I would find it quite convenient to use m-scripts that others had written and to use them with few changes or fragmentation. I can imagine that this implicit desire for a relative path option (since I now understand that this is what would be involved) could cause a lot of work on your part and understand that not all wishes are equally likely to come true.

Reading binary files which contain data from C structures (with their variable data byte sizes) can be difficult, especially if the data offsets have to be calculated on-the-fly. If you don't have an fseek function then in MathScript you seem to need to (a) check that the file is closed, (b) open the file and fread a slab of bytes to get to the correct point (c) fread the data you want, (d) close the file, (e)open the file and fread a slab of bytes to get to the correct point(f) fread the data you want, (g)close the file etc etc . With fseek  you can select data from the file in any order you choose and which is convenient. The ability to jump around in the file with a byte count input to fread (not just where it is after the previous fread) would be almost as convenient. The present MathScript fread functionality seems to assume that a file is read linearly from start to finish in contiguous chunks,  some of which may be discarded. I suppose that you might suggest that linear readout is the logical way to do things but sometimes I am at the mercy of my colleagues.

Regards,

Worried_of_Bexley

[GrantM]

Worried_of_Bexley,

Your feedback is very helpful.  I can see the use for the fseek function and the benefit of allowing paths to work for the file manipulation functions.  We will take this into account during future planning for adding and improving functions.

Grant M.
Staff Software Engineer | LabVIEW Math & Signal Processing | National Instruments

[Worried_of_Bexley]

Thank you.

Worried_of_Bexley