For Anyone that has some Time to Spare

[zerotolerance]

Hello Everyone. I'm PhD student at QMUL university. I was tasked with (2 weeks ago) making a program that controls a motor controller called Orbit FR and a VNA (I don't know its model yet). Trouble is, I don't have access to neither of instruments until 26th of August.

So until now, I've been trying to program Orbit FR instrument the best way I could from its manual. I believe I got most of it, but I'm not very confident in my programming skills, especially without having access to hardware.

Basically I was told to make the program look professional, and easy to work with for someone with moderate knowledge in Orbit FR instrument.

I have until the on Monday the 30th of August, the program will be formally used to measure some antenna patterns for a company (no idea which one), hence I only have few days with access to hardware (to tweak my program as needed) before the deadline.

So, I'm hoping for anyone that has some time to spare to help me "debug" or "reprogram" or "re-structure" my code so I have the best chance of success for the program to work when the time comes.

The part I'm mostly worried are:

1. Handling errors - I think I've done a poor job on this.

2. Sending commands to Orbit FR, since it uses SPOLL/PPOLL/SRQ for replies.

Included are ALL the material that I currently have. i.e. Main program with SubVI's and Custom controls, as well as the Manual that I've been using on Orbit FR. Inclusive are also some drivers that I managed to get from Manufacturer itself.

I used the JKI Toolkits to make my work easier, so you'll have to have it installed in order to open the VI's.

Thank you for any help, criticism, or suggestions that you might have, and please ask for any questions you might have.

On a long run, this exercise with your inputs, should definitely help me be a better programmer in LabView.

Thanks again for any input that you might have.

Kas

[gt3000]

Hello Kas,

I can't say that I have time to spare, but I will try and dedicate some time to helping you.  I have opened your attached VIs and have had a look.  Generally speaking your have employed a good structure with your application, especially with your subfolders for 'SubVIs' and 'Custom Controls'.  However, if you are using LabVIEW 8.0 or greater, you should also be using a LabVIEW Project Explorer Window with Virtual Folders that match your hard disk directory structure.  The Project File will ensure that if any VIs are of duplicate names, or missing, the user will be aware before opening the main VI.

The main VI is built around the JKI State machine which has proven functionality.  You can incorporate some improvements to make the code more maintainable over time.  There is a square on the Block Diagram that has 34 'Vertical' Booleans.  I recommend that you place all of the booleans into a Cluster which you can save as a Type Def. custom control.  Once they are a cluster, they will take up less space, but still maintain their own labels.  You can then more easily convert from cluster to array if needed, or apply a globaly change.

The State Machine states are being shifted as a 'String' constant.  It would be more scalable for the future if you used a Type Def. custom control Enum.  The Enum as both numeric and string properties.  As a Type Def., you can build a list of all the possible states as a fixed list.  If you decide to add more states, the entire Case Structure can adapt automatically with the new case names.  Also, it avoids logic errors because of mis-spelled strings.

Please try the suggestions out, as they will help you overcome issues in the future.  You can repost a new version of the Main VI or Project once they have been implemented.  I will see what else I can suggest after that.  I am installing the JKI tools now.

Regards,

[zerotolerance]

GT, thanks for your comments. Sorry that I couldn't reply sooner. I was trying to patch-up the program and employ your suggestions.

"you should also be using a LabVIEW Project Explorer Window with Virtual Folders that match your hard disk directory structure.  The Project File will ensure that if any VIs are of duplicate names, or missing, the user will be aware before opening the main VI."

This definitely was a good idea. Made it a lot easier to work with, especially when a number of SubVI's are involved. I did it and attached is the project file.

"There is a square on the Block Diagram that has 34 'Vertical' Booleans.  I recommend that you place all of the Booleans into a Cluster which you can save as a Type Def. custom control.  Once they are a cluster, they will take up less space, but still maintain their own labels.  You can then more easily convert from cluster to array if needed, or apply a globaly change."

I don't think this would be possible. The only reason I use those 34 button are for their "Boolean Glyph". Basically I need those Glyphs to be visible & hidden at appropriate times (When the received values are the same or different to Load values). So, If I put them in a cluster, I can't reposition the Glyphs outside the Cluster area, and I need those Glyphs to be on top of the main cluster "Controller Parameters". 

  "It would be more scalable for the future if you used a Type Def. custom control Enum.  The Enum as both numeric and string properties.  As a Type Def., you can build a list of all the possible states as a fixed list.  If you decide to add more states, the entire Case Structure can adapt automatically with the new case names.  Also, it avoids logic errors because of mis-spelled strings."

I found this to be slightly cumbersome, especially for a rather larger aplication. With "String' constant" I was able to load a large number of states at a time (sometimes more than 10) and with JKI template I was able to priorities the states. With Enum however, I found it slightly difficult to work with because of those issues. I did "GPIB COMM Link.vi" the way you mentioned and I feel its a little bit more messy.

Overall Updates that I've made:

1. Restructured the "Orbit FR - Main" code the best way I could.

2. Did a new subvi "GPIB COMM Link.vi" that is used to send and receive data.

3. Did a new subvi called "Track History.vi" that is used to track all the traffic to and from the instrument. Doesn't matter what type of communication link is used.

Attached is the new version

Thanks again GT.

Kas

[zerotolerance]

Further to my previous updates:

1) Added the "LOAD" and "SAVE" functionality. This enables the user to save settings and read them automatically.

2) Fixed the "Track History.vi". Initially this wasn't working properly but now it does.

3) Tested the program as much as I could and it seems to be working.

Question:

I am really not sure the way that I am reading the values back from Orbit/FR. When I'm reading the "Axis Position", I check through PPOLL.

There is a case called "Finished measurment?" that queries the instrument for an Increment through PPOLL, and when that happens I go and Read the X1 position (axis position). But, if there is no Increment, than I say the measurment is finished and I stop quering for "Axis Position". 

I'm not confident if the above method would work, but I have no idea how to do it better.

I would be greatfull for any input in this.

Thanks

Kas

P.S. As usual, attached are all the UPDATED VI's.

[zerotolerance]

Apologies for sounding desperate, but I'm still hoping that someone might take a glance at this. Especially my last question.

Thanks

Kas

[gt3000]

Hi Kas,

Thank you for posting the updated VIs.  I have installed all of the Open G and JKI examples you are also using and have tried inspecting the project. 

Unfortunately, my experience in using the absolute lower level commands for GPIB, such as PPOLL, is limited.  Most modern hardware tends to work correctly using NI-VISA commands, which is a higher level API encompassing all the lower level functions.  Are you sure you are not able to use the NI-VISA palette with your hardware?

As far as I can tell, your idea on how to use PPOLL seems correct for this example, however, I can not claim to be the authority on that.  One thing to point out is that the data that come out of the 'Parallel Poll Byte' terminal depends on how you have configured the instruments.  At some point your code, you may need to use a 'PpollConfig' VI.  The text below is from the Ppoll.VI help:

"parallel poll byte is the result of the parallel poll. Each bit of the poll result returns one bit of status information from each device configured for parallel polls. The state of each bit, 0 or 1, and the interpretation of these states are based on the latest parallel poll configuration sent to the devices and on the individual status of the devices."

As a reference, I have found online articles about Parallel Polling with instrumentation.

Parallel Polling Knowledgebase Article

Parallet Polling tutorial

Keep in mind that all software system require some interaction with their real hardware counterparts before the code can be fully debugged.  As you are UK based, it might be beneficial to continue this query over the phone when your hardware arrives.  However, some question, such as about PPoll, could be receive quicker answers on the forums from engineers with 15+ years of experience with GPIB.

Regards,

[gt3000]

Hi Kas,

In addition to my above post:

1. Are you using an NI GPIB card? Which one?
2. What is the Orbit/FR instrument model?
3. Have you contacted Orbit/FR for an existing driver or example code?
4. How is all of your hardware wired together?

Regards,

[zerotolerance]

You are right, before requesting a PPOLL from devices, PPOLL configuration is required. However, PPOLL configuration for Orbit / FR controller is implemented indirectly by means of COMM LINK COMMAND and not by the IEEE-488 PPC and PPU commands. Basically, the controller configures its PPOLL when the user issues a specific command (given on Page 59 on MAL-4806-3A_Comm Link.pdf ). The manual is provided in my first post, and on my latest program there should be a case structure called "Configure PPOLL" that achieves this.

NI-VISA can definitely be used, but this hardware has a peculiar way of sending back information to the user. The user will first have tro interrogate the hardware through PPOLL, SPOLL or SRQ Interrupt method, and then receive the information. I understand that you an do SPOLL using NI-VISA but I couldn't find a way of doing PPOLL or SQR with VISA. Mind you, I only need to use 1 of the three methods but I thought of using PPOLL since I have other hardware (i.e.. VNA) to communicate and PPOLL offers a faster way to communicate with more than one hardware. Page 140 of the same manual provides a COMPLETE example of Loading, Verification & Monitoring the hardware in different motions. But I really don't understand the text based language. I can't even recognize the type of programming language it uses.

Going a little bit deeper in this issue, manual also mentions that I need to have a command called "Bus Increment" set up in order to use PPOLL method. and everytime the controller moves past the "Bus Increment" value, a bit called "Increment" (page 17 of the same manual) of the PPOLL byte goes high. at this point, the manual says I can read the controller position directly using the ENTER command. I haven't the slightest clue what this ENTER command is. Does it just mean the I should just read the bytes that are present at the controllers buffer? I know you mentioned you don't understand this much, but I thought of giving it a try.

You also mentioned that there are "engineers with 15+ years of experience with GPIB". I'm not sure if it would be polite to give them a private message, just to point them to this post .

Thank you

Kas

[zerotolerance]

Answers to the above questions.

1. Yes. I'm actually using a USB-GPIB card that university bought a batch less then 5 months ago directly from NI. No problem with this, its working perfectly.

2. The actual model we are using is "MAL-4806-3C" but the PC commands are the same as "MAL-4806-3A". So the company haven't bothered making a new user manual for the newer version, they just said to use the old manual.

3. Yes. After much hassle, I was only given the basic code (provided on my latest post under a folder called "GPIB labview examples"). basically this folder contains all the Labview code I got from the manufacturer.

4. I'm basically just talking to 2 instruments. 1st is the Orbit / FR to move a HUGE antenna (quite heavy payload) and the VNA (of which I still don't know the type, at least untill the 26th or next week at the latest, which is why I wanted to at least get this Orbit controller out of the way first). The communication link is all done through GPIB.

I have previously done GPIB communication based programes successfully, but I'm really getting mixed up with all this PPOLL and SPOLL stuff. Not much experience in this area. Here I would've thought a thousands of £ controller on the 21st century would've at least honored the correct communication type without sending the user through all this hassle .

Thank again GT.

Kas

[gt3000]

Hello Kas,

I have looked at the original post, but the the ZIP file did not contain any manuals that I could use.  I have, however, found this manual online. 

http://www.trimcom.ru/d_page/pdf/4806/MAL-4806-3C.pdf

There is a lot of material for me to go through and understand, but I was hoping you could confirm that this is the right product. 

The next through I had was to find where else this product has been used an by whom.  You may find that many IEEE/IET papers on Antennas and Propagation have used this hardware before.  As you are part of QMUL, you could have access to these published papers.  It could be useful to check for any procedures that are outlines in these papers.  Some Google results for searching the above product point to published papers.

According to your last posts, we may have to shy away from using the VISA commands.  The GPIB commands with NI VISA are most useful when the hardware is fully IEEE 488.2 compliant.  However, one thing to bear in mind is that you can use NI-Spy to interrogate what lower level commands VISA is actually sending down to hardware.  It is just one more tool for you finally receive the hardware onsite.

Regards,