It's a matter of SCALE

[Mike Nash]

I don't seem to be able to SCALE Input 100.0 as an input . I tried 100.0:R and no joy either.

It works fine with R0 where R0 equals 100.0. I have In Min and In Max at 0.0 and 100.0 with the decimals.

Bug, or intentional? Or I haven't found the secret handshake.

[Bobby]

So you are attempting to add just the numerical value of 100? The First field called "Input" must be pointed to a numerical  memory location so maybe that is the issue. What are you trying to do with the SCALE instruction that you want a static input?

[BobO]

The input and output fields are variables. The Min/Max In/Out can be constants or variables.

[Mike Nash]

Well it's tricky isn't it? I never hit enter earlier. I see now that 100 in the Input gets changed to D100 only when I hit enter, and I get the green dot saying it's cool with 100, but not with 100.0

As for why? I didn't want to burn a memory I would have to keep track of and it's going out to a 16 bit analog output. I only want 100% in certain conditions. I settled for Move but it's not obvious that way what the scaling is.

[BobO]

You might consider a symbolic constant for that. Let's you assign meaningful names to numbers.

[Mike Nash]

I really hated having to assign values to V-mem in the DL stuff for those instructions that just had to have a memory location for one of the terms. This isn't really one of those cases as I figured it might not be an intended usage. I will probably just use a Real when I get the rest of that logic done and load it with a constant or variable as I need it. And LERP has clamps! Or just use one of those twisty convoluted (What was I thinking ?) Math boxes.

Earlier, when I was pondering how to get this process to work I had some pretty diabolical* Math boxes doing the logic for 16 different solenoids with only 3 or 4 rungs. I decided it was sweet, but too hard to troubleshoot later if something broke. So now that part's around 100 rungs and that's still using some indirection. To be fair, I did add 1 timer per solenoid for cycle time and 2 per for fault detection (but I could have used just 3 for all as only one fires at a time.)

This is where add on instructions would be sweet. Every time I decide to add a tweak I get to do it 16 times.

* Actually, I was having trouble even getting that little green dot that said I finally had all my conditionals satisfactory for three Ifs. The Ctrl-Enters helped for sure.
Oh and things like MATH C9 IF(COUNTIFEQ(1,C201,16),1,0) are cool.

[BobO]

DmD 2.0 adds true subroutines. Not yet user instructions, but should still be a big help.

[Mike Nash]

You might consider a symbolic constant for that. Let's you assign meaningful names to numbers.

So I had a bright idea, but only so-so results.

Idea: I would like to have the user data types such as Part1.AutoModePB and wondered if Symbolic Constants could give me at least Part1:AutoModePB . My results were not spectacular, but not a complete bust.

Things I found:

1) I already have a User Memory Type Punch0-30000, but I can add a Symbolic Constant Punch0 with a value of 12, but it is ignored. I can add a c301 but get the Nicknames must be unique! message with C301. Punch0 isn't unique either. I just noticed that it is only allowing me to enter the Punch0 from the Symb dialog and only if there is not a Nickname already the same. Trying to change an existing Constant to Punchxx anything tells me I can't. I can add d301 from the dialog, but not D301.

2) I cannot add a contact with an address of C[Part1] or a comparison of D[Part1]

3) I CAN have a MATH box with multiple Symbolic Constants Added and it works as intended, in the example C301 turns on C317. I was not able to CAST D100:AutoModeEnabled anywhere.

4) None of these make me lessen my desire for User Memory type Punch1_0-10, Punch2_0-10 or something like it. PunchI thru PunchXVI or PunchOne thru PunchSixteen as Memory types kinda fail the smell test. It is amazing how frustrating little things like that can be even when I know you have very valid reasons for the current limitation.

[BobO]

I am never disappointed in the creativity of users. Y'all see ways to try things that never crossed my mind. I'll address these when I get to a keyboard. I find my iPad or phone aren't suitable for anything other than brief posts.

You should not be able to create overload...two or more symbols that reference different things...but there may be holes, and I'm sure there are ways to back into it. You can get back to nickname overloads by leading with...crud, it isn't on the iPad keyboard. It's the single quote looking character that isn't actually a single quote. Upper left corner of the keyboard over a number. Anyway, tack that on the front to select the overloaded nickname.

And I am very sorry we frustrate you. We try hard to anticipate wants and still keep grammar that works for everything. While our symbolic constants work kind of like defines in C, they are actually special element identifiers that get replaced with constants at code gen. So when you enter C[symconst], symconst is an element that isn't a V, hence it doesn't work. If symconst was a nickname for V, it would. But if symconst is 5, you are just referencing C5, which can have a nickname.

Anyway, more later...

[Mike Nash]

And everything I came to purchase is almost always behind the floor display or the giant warehouse step ladder, or they quit carrying it because they never sold any (since there never were any there to sell.)

I tried a little more this morning. Yes, I can have a nickname for V150 and use that as C[nickname_here] and wherever V150 points that is used. But I can't use anything but numbers 0-7, 0-15, 0-31 for bit casts, so D[Part1]:12 is good, but not D[Part1]:Constant12, oh well.

Yes, I think User Structures would be really handy when you get to that point. (See, I figured out "Structures" is the right term.) I didn't see any existing ones I could easily co-opt though. The real danger in being "clever" is that the cool workarounds are subject to change at any time since they are not supported.

I happened upon possibly the only version of RSLogix 5000 once that interpreted CPT R1 = 10*R0 as 31.4159 (Where R0 and R1 were floats and R0 = 3.14159). At the next update, it was now computed as 31.0. Changing the 10 to 10.0 fixed it. This has been it's normal behavior all along (first term type determines the calc type) but I had forgotten and this slipped through as it did work correctly when tested. That was a head scratcher. (Actual values were different, but similar.)

[BobO]

I realize it is of little consolation, but there is simply no room to store some of what you're wanting. The basic element storage is 5 bytes, dating from 1992. We've talked about opening that up eventually, and I'd say we will, but we kept it the same to minimize impact to pre-existing DmD code. As a small company trying to do big things, you have to pick your battles.

[Mike Nash]

The really strange thing is how 2 years ago I didn't much care for this whole concept of User Structures because you have to stop and grapple with understanding how someone else set things up (or even me a year ago.)

Add on instructions are cool from a "writing the program" standpoint. Not quite as great when troubleshooting. (I've seen inside a couple that looked like dumping grounds for discarded attempts at something arcane.) Worse when the attitude moves toward leaving useful instructions out of the programming package because the user can "simply build their own" from primitives - oh yes, bring your own primitives too. (I'm not saying Host has done this!)

I for one truly appreciate where you are heading with this and how far you have come. So many of the projects over the years would have been so much cleaner and easier with the Do-more versus the DL series. I still like the accumulator math for some reason I probably shouldn't look too deeply at.  I hate the Hex, Binary, Decimal, BCD ambiguity of the DL stuff though.

The Do-more has certainly been a "give me an inch and I'll want a mile" experience. Good Stuff.

[BobO]

The Do-more has certainly been a "give me an inch and I'll want a mile" experience. Good Stuff.

I'd be disappointed if folks didn't ask. I'm also disappointed when I can't give them what they've asked for, but please don't stop.

[Controls Guy]

I for one truly appreciate where you are heading with this and how far you have come. So many of the projects over the years would have been so much cleaner and easier with the Do-more versus the DL series.

+10 ^ 6

I still like the accumulator math for some reason I probably shouldn't look too deeply at.  I hate the Hex, Binary, Decimal, BCD ambiguity of the DL stuff though.

You can do some weird OoB stuff when you can tweak the accumulator directly.  Push stuff on there and call a subroutine, for example.  Even so, the frequency and magnitude with which it helps you don't make up for it being a pain in the butt the other 99.4% of the time.  Totally concur on the encoding (and don't forget accursed octal addressing plus no typed memory)

The Do-more has certainly been a "give me an inch and I'll want a mile" experience. Good Stuff.

Oh yeah! (both counts)