You could try sending the correct termination character. As the manual states, you need to terminate with a CR (\r). You set the termination to LF (\n). You'll also want to verify that you are using the correct type of serial cable (null modem or straight-through).
Looking at the driver, I don't see where you got the idea you need to use the VISA wizard to create an inf file. It seems to me, the usb dll that the driver calls will take care of all the low level communication. You do not need to have the instrument appear in MAX. Undo everything that you did so that the inf file from the vendor is the active one.
The SampleQuery VI looks extremely simple if a little crude. What exactly is confusing? If you click the 'Send' button, it writes a command to the instrument and then does a read. If you click the read button, it just does a read. Nothing more complex than that.
I've written applications with these drivers, for the NP 1931, and had no problems with them.
I installed the Newport meter drivers which came on the CD which ships with the meter, plugged in the meter via the USB port, established that the device was talking, and then wrote the LabVIEW code using the functions found elsewhere on this thread (NP_GeneralDrivers_LV8.llb). MAX was not involved. The VIs work fine. I admit that they aren't very well written from a coding standpoint, but they talk to the device and it talks back.
Are you using the USB port or the GPIB bus? If you are using the USB port, then you need to specify that for the function by wiring in a "F" value to "Build Instrument Channel". See below.
Hope this helps.
Its a postive that I can choose to use a straight cable from the Newport meter to the PC. Because the Newport Device is a female port and the PC is a as usual male. (Currently on USB connection)
The Sample Query does work properly, but then when i try to built a very simple VI that does what I/O Insturment does, (Query and Parse) using their Instrument Drivers, I keep getting a pop up warning saying the error inputs are not "wired" correctly or set correctly. (If you notice, there are error ins and outs)
So the only way i could do is to play around and modify the sample query example.
Now i get the picture, It calls for a .dll which handles the low level comminications, (it was presumably made to behave this way?). I will try out your method of using ActiveX to call the dlls and wired other components i need. (Basically real time measurements OR taking measurements at specific intervals) Any tips in how to approach this? I was thinking using a timed looped (while loop and Wait for next interval icon under 'Timer" functions) but had to understand a lot of its logic till i could not master the use of it.
Pardon for my ignorance of programming logic knowledge. Because I am faced with a tight time schedule to develop a simple VI to automate the value measurement and there are so many other areas to manage in the fabrication and real experimental setup. So i am now trying to minimise development time.
May I know whats the error wiring's purpose? As in wat's the reason in wiring the error terminals and what are they wired to? (Olive green icons...)
I will bear in mind the False const for the build instruemnt channel icon. I am using USB currently.
Yeah i think I recently got to understand the working basis for the Sample Query VI. Basically i am highly inexperienced in using Labview. Because i only went through a very short and introductory crash course on knowing labview. So I am unable to identify this particular property having dlls involved. At that point of time, it is only obvious to me the options i can exercise to communicate with the instrument. You could see this more of being highly inexperienced user who needs a realistic and feasible purpose for a VI but face many unforeseen circumstances in having the instrument to interface.
But thanks for the pointers about the Sample Query VI, because i just figured this out a day ago after i posted this thread
You've posted some very confusing information. Your instrument I/O assistant is configured for RS-232 and now you say you have a USB connection. Not at all the same.
ActiveX has absolutely nothing to do with the driver or the instrument.
If you have a problem with your code and the wiring, post an image or the actual VI.
I believe I laid out the situations of trial and error in my first post. Whereby i tried both USB(Driver creation wizard) and RS232(Inst I/O Asst) (but not simultaneously) initially without Newport's sample drivers (aka LLB). These two inital tries were done to get the insturment to talk with my limited knowledge back then and without the posession of the sample drivers during these two initial tries. I then highlighted within the same first post that there after I manage to get hold of the sample Labview LLB from Newport and it works with the USB connection OR the RS 232 via the Sample Query VI off the box. From this point, I wanted to build a simple functionality (from ground zero using the VIs within the LLB) which is to extract measurements at set intervals basing on the provided LLB by Newport.
The activeX was highlighted by one of the engineers from NI to call the related dlls but this was his recommendation of how can i approach my issue I have currently (again the first post). According to the engineer, the dll for low level communication (if there is a more elaborate explanation or a tutorial i could refer to, that will help a lot.) It's only after this post, I got the drift that there is no need for MAX to recognise the device in order for communication since the LLB is calling dlls for communication. In essence, this was the recommendation for getting the communication infrastructure (allowing it to talk).
Diane, the next reply showed me an example VI she conjured to answer my query on building from ground zero a VI for the purpose I desired. So i was asking her what is the purpose of wiring the error terminals, where does it lead to and its purpose. (As seen from her olive green wires from the query blue icon). I have attempted to do from ground zero and I face difficulties which I interpreted as something to do with the error terminals.
I hope this clarifies on the chronology of the experience I have undergone thus far and simultaneously posting some revelations gotten from all of your replies.
Error connections server a couple of purposes. First, when you wire the error out from one function to the error in of the next, typically, the next function will not execute. It will just pass the error through. At some point, you would have an error handler. This could be as simple as displaying what the error is and where it occured. Using a front panel indicator will work. You can get much more sophisticated with your error handling. Second, the connections enforce data flow.
A quick screenshot of a couple of the things Dennis mentioned...
The top loop shows the error condition stopping the loop, and the error is handled outside the loop. The bottom loop shows the error being handled and cleared inside the loop, without stopping the loop. It's just to illustrate a couple of methods for very basic error handling. A lot of people will choose to skip the "error handling" part of their code, but I don't recommend that. Error handling is very, very important and should be given just as much consideration as the rest of the code functionality, in my opinion.
Otherwise you get a LOT of complaints from your users.
Does that help at all?
Definitely helps and clarifies the issue. Seems like i have to go to the drawing board with all these info and pointers.
Thank you all for the contribution!