Host Engineering Forum
General Category => Do-more CPUs and Do-more Designer Software => Topic started by: Mike Nash on April 04, 2016, 04:25:58 PM
-
I have somehow managed to get SS0-4, SS15, SS16 and SS31 stuck at a MaxLen of 40 with all the rest at 64 as they should be. This probably happened when I was messing around days ago and found the Cmore EA9 was only allowing me to enter 40 characters and I may have dropped the SS string length in Memory Configuration. I really don't know. I have since increased the table size to 150 (SS0-SS149) and the string length is greyed out and showing 64 there. I need these back as I am pre-pending Time and Date to these strings so it's hacking off the text at the end.
So how do I fix this and not lose the info in the SS's?
(I am still having issues with Memory View and Memory Image so I don't know that I can save the values out and get them back.)
Thanks!
-
I went ahead, took the chance and set the SS memory size to zero and then took it back to 150. This got all the SS.MemLen back to 64, yea!
However, my string routine seems to be my issue. I did find I can edit the string in a data view and it will go back up to 64 characters.
So, I found my problem, but don't quite understand it. I was memcopy'ing a 40 character string to another one, then trying to STRPRINT to that another one and it was only printing 40 characters worth instead of 57. Deleting the (leftover) Memcopy solved the issue, but I don't understand the length being restricted at all in this fashion?!?
-
So does anyone know if there is a 40 character limit on strings in the Cmore EA9 v6.14? Now that there is a 57 character string in the PLC, Cmore stops displaying after the first space since the rest is 40 contiguous characters I guess. Looks like I may be back to 2 strings per item anyway, bummer.
-
There is no such limit that I know of. I can't say that I have ever tried to display that many characters before though...
-
Have you checked how you set up your SL tag in the Cmore tag database? Maybe the character count is wrong there?
-
Slap! I got bitten partially by the coincidence bug even though I am a firm believer in coincidences. I had the Cmore Dynamic Text object ever so slightly too narrow. Apparently, Cmore simply tosses out any part of a text string that won't fit as long as there is a space to break at. You get nada if there is no space. Pretty ugly behavior. I had checked my width with a static text object with the same font characteristics in the editor, but it wasn't quite enough - adding 5 pixels fixed it - Courier New so fixed width. I need a prettier fixed width font!
That explains the Cmore not displaying all of the string. I am still not understanding why the MaxLen would get shortened and be unable to put a longer string into it via code.
I could not get more than 40 characters from the Cmore to the PLC still.
And I am using SS rather than SL as 64 characters is more than I need.
-
Have you checked how you set up your SL tag in the Cmore tag database? Maybe the character count is wrong there?
Ha! Yes that was another self-inflicted. I was 2 bytes short and had 56 instead of 58 - I need 57. I found that before the object width.
-
So, I found my problem, but don't quite understand it. I was memcopy'ing a 40 character string to another one,
When you say "40" here, do you mean you had STRING block with Max Length of 40 characters that you were copying into SSxxx, or that the length of the string contents was 40 characters?
-
Normally, when trying to do a MEMCOPY between two dissimilar sized STRING blocks (e.g. SS has buffer/max length of 64 characters and SL has buffer/max length of 256 characters), you should get an error when trying to enter that instruction (see attachment).
-
I am getting more like what I expected this morning. Including the MEMCOPY then the STRPRINT to the same SSx working ok without dropping characters.
Maybe just a bad case of HUHS?*
1) C-more will not always display all of a string. If it has no spaces in the string it will display as much as it can in a too narrow text object. If it has a space, you only get up to the last space that will fit. Leads to confusion.
e.g. 123456789a123456789b might show 123456789a123 but 123456789 1234567 would only show 123456789
2) When C-more writes a 44 character string to a Do-more SS location, the SS.MaxLen is set to the length C-more has for the tag. If it was MaxLen 64 and C-more writes a 23 character string, MaxLen becomes 44 in the Do-more. Why? What does this mean? If I change the size in the tag name database in C-more to 58 and write another string, MaxLen will change 58. If it sends a shorter length MaxLen does not decrease in size. At least this is what I think I am seeing.
Checked some more - I can data view edit a 64 character string into SS0 and SS0.MaxLen goes to 64. C-more then writes a 29 character string to SS0 and SS0.MaxLen is now 44 (which is the size I have set in the C-more Tag Database for the SS0 string only.)
So again, what is MaxLen's purpose and personality?
3) The tricky part seems to be that once C-more has set SS0.MaxLen to 44, a MEMCOPY from SS0 to SS147 results in SS147.MaxLen also dropping from 64 to 44. Now if I try to STRPRINT a longer string into SS147, it does not have enough room as it clips after 44 characters. Without the MEMCOPY, SS147.MaxLen stays at 64 and I can fit the STRPRINT result into just fine.
* Head Up Heinie Syndrome
-
The Length in C-more MUST be set to the Max Length of the string of the specific Do-more block. If it's 64 (e.g. SSn), then you must set that tag's (max) length to 64, NOT 44! If it's 256 (e.g. SLn), then you must set that tag's (max) length to 256.
The .MaxLen is meant to be READONLY and can really mess up/corrupt your memory (especially if you make it LARGER than the actual buffer allocated for each string!!!).
-
So, please re-do your C-more configuration for ALL the tags and make sure they match the SS block .MaxLen (64).
Also, a PGM->RUN transition SHOULD re-initialize all your .MaxLen string structure members to their proper values (i.e. 64 for all the SS strings, 256 for all the SL strings, etc.).
-
1) C-more will not always display all of a string. If it has no spaces in the string it will display as much as it can in a too narrow text object. If it has a space, you only get up to the last space that will fit. Leads to confusion.
THAT's extremely lame. It should just show what it can and truncate. >:(
-
So, please re-do your C-more configuration for ALL the tags and make sure they match the SS block .MaxLen (64).
Also, a PGM->RUN transition SHOULD re-initialize all your .MaxLen string structure members to their proper values (i.e. 64 for all the SS strings, 256 for all the SL strings, etc.).
I am not writing to the .MaxLen at all. I know Data View doesn't allow it. That is just the behavior I see when the C-more writes to the string.
The issue I have with allowing the C-more to have all 64 characters for input is that I have no way to limit what the operator types as he is typing other than the tag character length.
It's bad enough the C-more text entry has no cursor, no loading of current value, and nothing better than backspace, clear or cancel for editing what is being typed.
Maybe I can have them enter a string to an internal tag and event manager it to the PLC string. I'll check that.
-
1) C-more will not always display all of a string. If it has no spaces in the string it will display as much as it can in a too narrow text object. If it has a space, you only get up to the last space that will fit. Leads to confusion.
THAT's extremely lame. It should just show what it can and truncate. >:(
Some days I begin to wonder whether I am the only one having these issues.
But more likely I am just the squeakiest wheel. :D
-
Mike, If you can give a little more detail as to exactly what you are trying to do then maybe I can help. I have dome some pretty deep string manipulation between C-more and Do-more.
-
Some days I begin to wonder whether I am the only one having these issues. But more likely I am just the squeakiest wheel.
I don't have C-More issues because I don't use C-Mores, but all HMI's do weird things you have to accommodate. My current preference, mostly having to do with the TFT they use (brightness, saturation, resolution, etc.) is Idec, but their software is no better than anyone else's.
In fact, the cheapest HMI's, C-More's and the AVG's sold by EZAutomation.com, actually have some of the least annoying software as HMIs go. I just don't use them because the actual screen hardware isn't as good.
-
I am not writing to the .MaxLen at all. I know Data View doesn't allow it. That is just the behavior I see when the C-more writes to the string.
We know you're not. We think that C-more is writing the entire structure, rather than just the relevant parts, and would be overwriting the read-only MaxLen with bogus data. The low level comms do as little error checking as possible to minimize performance hit, assuming that comm clients are playing by the rules. It seems that C-more is not.
As an aside: When we first released Do-more we didn't allow any HMI to use the programming protocol for exactly this reason. My preference remains that all HMI should go through quarantined memories like Modbus and DLxxx, but, customers complained and ADC asked us to reconsider the policy. We may need to add some additional checking to prevent this. Fortunately, it only affects writes, which should be comparatively rare.
-
But more likely I am just the squeakiest wheel. :D
Squeak away, my friend. We listen.
-
(https://forum.hosteng.com/proxy.php?request=http%3A%2F%2Fstatic4.businessinsider.com%2Fimage%2F5499948c6bb3f74d611468d6%2Fthe-truth-about-the-most-interesting-man-in-the-world.jpg&hash=12ad7be1927881973ec87bc5037843cc5425f773)
Stay squeaky, my frensss!
-
Mike, If you can give a little more detail as to exactly what you are trying to do then maybe I can help. I have dome some pretty deep string manipulation between C-more and Do-more.
Basically "duplicating" the functionality of an old Giddings and Lewis system that I don't get to see the original code of. I looked at using the C-more recipes, but frankly keep shying away from them. I like the idea of the recipes living in the PLC better.
So the issue area gets down to the lacking text input functionality in the C-more. I am using the User qwerty keyboard with a few tweaks to give more symbols (and I originally had no comma, but I can't remember what it was inputting.) That's another issue as an aside. I copied it and modded it and now I can use the copy, but can't find it in the keypad screens anymore.
So I am wanting to have the operator allowed to enter a recipe description of no more than 40 characters. I then create a date and time stamp string from the PLC clock and append what the operator entered. All 60 recipe numbers and time-stamped descriptions are on one screen simply as a recipe parts list. The desired recipes for a job are entered by the 1-60 numbers (any 5 in any order even duplicated, 0's for unused.)
All of that is working properly, except I can't limit the C-more string to 40 characters per franji1's advice. OK, I can, but I have to be very careful how I handle it afterwards because it is highly infectious towards other strings. Oh, and if anything bad happens there's a trail of evidence pointing straight to me.
I did look at some kind of event handling but every time I had another ah-ha idea it had already been anticipated and blocked. Pretty frustrating.** At this point I will probably just snip it in the PLC and be done with it.
And on the Run screen, where the 5 (or less) "chosen" parts reside, I strip off the time stamp and just show the description the operator entered.
So I guess I have enough of a handle on this at the moment that I am moving on to the extraneous I/O logic and the other 2 servo CTRIO2's. The real booger was wrapping my head around blending those chosen recipes into a linear progression through a machine. It's more like scheduling than anything else, no steps can be missed because you can't go back, you can never go back. Well, until the last piece of the order drops off and then you can back the hopefully still unblemished material out 20-30 feet.
Anyway, I tend toward verbosity rather than succinctness.
Thanks plcnut. I've played with strings in QuickBASIC and others a good bit, mostly long ago. The Do-more terminology is a little different but seems to work well for this.
And thanks HOST! I am pretty amazed when I look at how little code I have actually written to get some pretty powerful results. And still at 1.2mS max so far. I'm not the best planner in the world, I much prefer the just try it and see approach. The Do-more makes this pretty painless indeed. I have actually found myself looking at what the logic churned out to make sense of the numbers. It was usually easier than Excel though I used it extensively trying to understand the pattern I needed to see.
*(especially after I finally realized all of the Ctrl-C Ctrl-V's I had done were indeed being processed - even though I was clicking on the pushbutton object each and every time before Ctrl-C, it was copying entire screens over in the left pane instead, site unseen. C-more has a focus issue, even the tag name tool tips intercept and steal mouse clicks.)
** I do have some event manager sounds working finally, but found that just because it is a .wav file does not mean C-more will play it. It has to be PCM format or at least not CCITT u-law. The simulator played those fine.
-
And thanks HOST! I am pretty amazed when I look at how little code I have actually written to get some pretty powerful results. And still at 1.2mS max so far. I'm not the best planner in the world, I much prefer the just try it and see approach. The Do-more makes this pretty painless indeed. I have actually found myself looking at what the logic churned out to make sense of the numbers. It was usually easier than Excel though I used it extensively trying to understand the pattern I needed to see.
Some of the highest praise you could give us and absolute music to my ears. Thank you!
-
Point your text input at MHRs or other integers instead of Do-More strings. For years, that was the only way we had to do it and the C-Mores handle that just fine. Then you don't have the length issues.
-
Point your text input at MHRs or other integers instead of Do-More strings. For years, that was the only way we had to do it and the C-Mores handle that just fine. Then you don't have the length issues.
Thanks! I'll give that a whirl. I am happy with the C-more's displaying of the SS strings (now that I know what to watch out for), just that single one is used for input. Do-more massages and moves it where it is needed. I would really prefer C-more limit the entry to 40 characters so that may be the way to do it for this one.