Sgl write file error 4

[DavidIMurray]

Hi

I've got a system out on site that writes a binary file as required by a set of parameters that are read in from a text file. However I've started to see a problem that makes the system hang. I've attached a screenshot of the error - any ideas why this is occurring. I'm not sure why a write file operation is causing an end of file error.

Cheers

Dave

[smercurio_fc]

Without seeing some code it's kind of hard to pinpoint - we can only guess. Are you programmatically setting the file position? Could be an error in the way you're calculating that.

[DavidIMurray]

Hi

I've uploaded the code to -

www.geocities.com/davidimurray/Labview/HM-SystemV3.llb

The main vi you want is the HMsystemv3.vi

Cheers

Dave

[smercurio_fc]

I would start with doing some code simplification:

• In calculating the HD information you're converting the path to a string, splitting at the "\", then adding the "\" back in, and then converting that to a path. This is to just get "E:\". This can all be accomplished with the Strip Path function:
  
  
• You have a timed loop for reading a file. What's changing this file? Why is it a timed loop?
• In the section where you're writing to a file you're duplicating what the "Write to SGL File" already does. You're going through and creating a new file based on a name change, and then opening the file, and then feeding the path to the "Write to SGL File". This is redundant. Simply feed the fully qualified filename (i.e., complete path to file) to the "Write to SGL File" VI. This VI will handle creating the file if it doesn't exist or open it and append to it if it does. This will eliminate your sequence frame and most of your string/path conversions as well as the need for the feedback node.
  

Message Edited by smercurio_fc on 06-13-2007 10:26 AM

Message Edited by smercurio_fc on 06-13-2007 10:26 AM

[DavidIMurray]

Hi

Thanks for looking over the code.

The code was written when I was starting with Labview - I'd yet to discover the split path in those days.

The timed loop is also a carry over from a previous implementation. A DLL was used to read a value from the process control system server. However, we had a lot of problems with making the DLL operate reliably so we came up with an alternative system. A stand alone data providing app writes a string into a text file, labview then reads the string and extracts the values for coil number, roughing pass and whether the system should log or not. When we used the DLL we had to only poll the server a maximum of once a second or there was a risk of overloading it with requests. I left the timed loop in to try and reduce the potential chance of the read file operation in labview clashing with the write file of the stand alone app.

I didn't realise that the write sql vi would automatically deal with file creation / change - I will have a look at changing this.

Cheers

Dave