DIO Port Write/DIO Port Config

[Dennis_Knutson]

I also agree that the best solution would be to switch to DAQmx. And I never use MAX for the task creation/save. I have never trusted the users of my software to not go into MAX and make accidental/deliberate changes.

[ispollock]

I have to admit that a lot of what you guys suggested has gone over my head, but let me see if I can clarify.

The VI I'm updating is really a one-off deal. The point of updating it is mostly so we can run it on a new computer and a new version of LabVIEW; the old program actually works quite well. Also, the VI is pretty complicated and was written a long time ago; nobody here really wants to revamp it entirely. That's why I'm reluctant to re-code the thing.

It now appears that the only remaining obstacle is a missing file:

DIGPRTCF.lsb

that the DIO Port Write/Config subVIs need in order to work. I've looked from pillar to post on our hard drives and I don't think the file exists there. Is there a possibility of downloading it somewhere?

Thanks for your patience,

-Ian

[hecmar.arreola]

Wow.  I really think MAX is the best thing since slice bread.  I can track calibration details in it and with table scaling it is easy to add scaling for non-linear transducers.  Not to mention the fact that it is completely documented by NI.  If you guys insist of re-making the wheel and documenting your process, have fun :).

[Dennis_Knutson]

Not sure about the cal details but everything else you mention is available in LabVIEW (which is pretty well documented). LabVIEW can write and save task information to MAX as well as just doing a read. I need the security of configuring everything in code that cannot be modified. I also don't need the phone calls at 3:00am because some file somewhere has been modified and the program is no longer working.

[ispollock]

Would it help if I added screenshots of the problem area? Maybe it's not so hard to update the code after all, and the whole thing's down to my inexperience...

[hecmar.arreola]

I understand different situations.  I like that I can have my coop add a transducer or a control to a system through MAX and not have to mess with the LabVIEW code, recompiling, re-distributing, and most importantly not having to bother me about it.

LabVIEW is very well documented... but how documented is the code you produced?  Only as documented as you make it (which is all work).

IMHO: LabVIEW is to MAX as CSS is to HTML.  When I started programming in LabVIEW, I was working with traditional DAQ w/ no MAX and I'd hate to have to ever go back.

[CoastalMaineBird]

If you guys insist of re-making the wheel and documenting your process, have fun .

If MAX did what my clients needed, then I would use it.

If the only thing I used was NI stuff, then I might use it.

If you want to tell your customers that they have to use TWO different methods for channel configuration,  MAX for NI stuff, and something else for the other stuff, have fun 😉

[Dennis_Knutson]

Well, I like the fact that a user can add a channel or scale to a system through LabVIEW and not have to mess with the LabVIEW code, recompiling, re-distributing, and most importantly not having to bother me about it.

MAX and LabVIEW are really just two different ways to the same information. The difference is that MAX already has a GUI to create the information while you hve to write the LabVIEW code to do the same thing.

One other thing that really bugs me is when someone posts some code to the forum and asks for help. All that is on the block diagram is a reference to some task. Then you have to go through the painful process of asking for all of the details. I don't mind if the poster can't get an immediate answer but I do  mind that it's extra work for the person trying to help.

[CoastalMaineBird]

 I like the fact that a user can add a channel or scale to a system through LabVIEW and not have to mess with the LabVIEW code, recompiling, re-distributing, and most importantly not having to bother me about it.

You're implying that the alternative to MAX is changing the code every time you want to change the config. 

I have never used MAX, but I have never faced the situation you described, either.

I wouldn't dream of hard wiring some configuration into the program. 

I have always (since lonnnnng before MAX) used config files with all necessary information in them, that the user can edit and change names, scales, active/inactive, units, etc. in.  

Right now, I have a project with 200+ channels, AO, DI, DO, some are NI, some are calculated, some are on TCP connections.

They're all the same to the user. 

You want to move it to a different computer?  just move  this folder.  No muss, no fuss.

 MAX and LabVIEW are really just two different ways to the same information. 

I don't think so. MAX only knows about NI stuff, right?  How would I configure my calculated channels, which come out of a plug-in VI, in Max?  How would I take to my gas analyzer (via TCP) and scale that through MAX?

MAX has it's place, but  let's don't claim it's just as good as code.

Message Edited by CoastalMaineBird on 04-03-2009 02:55 PM

[ispollock]

 Okay, I'm attaching screenshots of the subVI that's causing the trouble, incorporating the pinouts of the DIO Port sub-subVIs.

Loop 0, with DIO Port Config pinouts

Loop 1, with DIO Port Write pinouts

So I've tried replacing DIO Port config with the DAQmx virtual channel VI (set to Digital Input), and replacing DIO Port Write with DAQmx Write. The trouble is I can't seem to get the pinout correspondences right. I think:

- Task-out of the Virtual Channel should lead to task-in of Write

- All the error in/out wires stay the same

- The blue data wire (coming from the case structure) should lead to the data terminal of write

What I really don't get is:

- Where the device wire should go

- What should enter the task-in terminal of the Virtual Channel VI.