Just starting out...

agrajag42 · Dec 23, 2015

n00b question.

I'm using an AB 1769-OB32 output card in slot 3.

I can set an output bit by writing to Local:3.0.Data.0

I've got a FOR loop in a main program, that is incrementing a counter, and running a second program.

I'd like that second program to set an output bit (to control a valve) based on the count. So if the counter is at 0, it will control the valve at:
Local:3.0.Data.0
if the counter is at 2, it will control the valve at:
Local:3.0.Data.2

My counter is named current_valve. It's a DINT.

I'd think that Local:3.0.Data.current_valve would work, but it returns an error with:
Error: Rung 2, XIO, Operand 0: Invalid member specifier.

What am I missing?
Thanks!
/e

ASF · Dec 23, 2015

Welcome to the forum!

I'm not sure I completely understand what you're trying to achieve there...but that's not the question you want answering!

When using indirect addressing, the member specifier (which in your case is current_valve) must be enclosed in square brackets.

Local:3.0.Data.[current_valve]

I've never tried indirectly addressing an output per se, but I can't see any reason it wouldn't work just the same. I'll have to try it and see how it goes!

Side note: there's a reason I've never tried indirectly addressing an output. If someone is looking for a spare output later on, they may well pick the one you've indirectly addressed, because if they run a search for it and come up blank (which they will), they'll assume it's unused. You'd be better to indirectly address an internal tag, and then map your inputs and outputs in a separate routine, with comments on each I/O point to explain what they are (or that they're spare). Everyone who ever plays with you code later on will thank you! Search the forum for threads on I/O mapping if you're not sure what I mean, or want some more information on how/why you should (or shouldn't) do it.

ASF · Dec 23, 2015

I just tried indirectly addressing a digital output using the square bracket, and it compiled correctly. It was on the base unit of a 1769-L16ER-BB1B, not on your 1769-OB32, but I can't see any reason it would be different.

agrajag42 · Dec 23, 2015

Fantastic! Thanks for the quick response! I've got a lot of new directions to research, and a better picture of what the right thing to do is here, which is exactly what I was hoping for.

I'll check out the IO mapping, but I did try what you suggested. When I use:
Local:3:O.[Data.current_valve]

I get an error that says:
Error: Rung 2, XIO, Operand 0: Referenced tag is undefined.

current_valve looks quite defined to me... it's a program tag (in the same program). It looks like a 32-bit DINT with a current value of 0.
/e

ASF said:
Welcome to the forum!

I'm not sure I completely understand what you're trying to achieve there...but that's not the question you want answering!

When using indirect addressing, the member specifier (which in your case is current_valve) must be enclosed in square brackets.

Local:3.0.[Data.current_valve]

I've never tried indirectly addressing an output per se, but I can't see any reason it wouldn't work just the same. I'll have to try it and see how it goes!

Side note: there's a reason I've never tried indirectly addressing an output. If someone is looking for a spare output later on, they may well pick the one you've indirectly addressed, because if they run a search for it and come up blank (which they will), they'll assume it's unused. You'd be better to indirectly address an internal tag, and then map your inputs and outputs in a separate routine, with comments on each I/O point to explain what they are (or that they're spare). Everyone who ever plays with you code later on will thank you! Search the forum for threads on I/O mapping if you're not sure what I mean, or want some more information on how/why you should (or shouldn't) do it.

ASF · Dec 23, 2015

Whoops, got my square bracket in the wrong place! It's only the member specifier current_valve that needs to be in square brackets.

Local:3.0.Data.[current_valve]

I'll edit my post above to avoid misleading the nice people from the future

agrajag42 · Dec 23, 2015

Hah! You'd think I could have figured that out. I was trying:
Local:3:O.Data[current_valve]

...but I hadn't tried it with the period between the "Data" and the [current_valve]

You have saved my productivity for the evening! Thank you!

ASF said:
Whoops, got my square bracket in the wrong place! It's only the member specifier current_valve that needs to be in square brackets.

Local:3.0.Data.[current_valve]

I'll edit my post above to avoid misleading the nice people from the future

bernie_carlton · Dec 23, 2015

If 'current_valve' is actually a COUNTER type then you will need to use 'current_valve.ACC' between the brackets.

If 'current_valve' is just a DINT which you are incrementing and therefore calling a 'counter' because of its usage then 'current_valve' is just fine.

osmanmom · Dec 23, 2015

are the counter word or bit ?

agrajag42 · Dec 23, 2015

This particular issue is resolved -- I'm now trying to figure out the next issue, but I'll give it some serious effort before bothering you all again

bernie_carlton: Good point. It's just a DINT, not a COUNTER type... this time. That may have tripped me up in the future, though.

osmanmom: I'm not sure I followed your question. current_valve is a DINT, shown in Decimal. It has 32 BOOL positions listed under it in the Program Tags window, so I'm assuming it's 32-bit.

Ken Roach · Dec 23, 2015

I'll jump in and warn you that a classic mistake made when doing indirect addressing of bits in a DINT is that the OTE will only turn True the currently-addressed bit.

If you were running Output 0 with an indirectly-addressed OTE and turned the index value to 1 before turning the rung False... then Output 0 stays true.

If there is a simpler but more "verbose" way of doing what you want to do, choose the simpler method. Folks who troubleshoot it later will thank you.

willxfmr · Dec 24, 2015

+1 for Ken's comment. While using indirect addressing in this way is very clever, it would be a bear to troubleshoot. If you are doing this as an exercise to see if it can be done, then good luck, I hope it works. If this will be in a real life running program, please find a different way. The one thing we day sleepers hate is to try and sort through "clever" programming at 1:30 AM.

Will.

Just starting out...

agrajag42

Member

ASF

Lifetime Supporting Member

ASF

Lifetime Supporting Member

agrajag42

Member

ASF

Lifetime Supporting Member

agrajag42

Member

bernie_carlton

Lifetime Supporting Member + Moderator

osmanmom

Member

agrajag42

Member

Ken Roach

Lifetime Supporting Member + Moderator

willxfmr

Lifetime Supporting Member

Similar Topics