Certification
Non default used on typedefined constants
Control terminals on the connector pane should be on the top level block diagram, meaning outside of any case or loop structures.
The first one is probably so obvious that I don't know what it means 
I know this question is two years old, but I was wondering...
How would you handle a typedef'd cluster that looked better, in one orientation on the FP but in the other on the BD? For instance, a cluster of references that looked better sized horizontally on the FP, but was more compact vertically on the BD?
That's one reason I want to do something like modify the orientation on the constant - but I also know that every time you update the typedef, it will revert to the typedef orientation. Would you choose to go with the FP orientation so it looks good on the FP, sacrificing compactness on the BD, or would you go with the space-saving BD orientation and have the potential for the FP control to grow downwards and run all over your FP? Or is there another solution where I can have the advantages of both?
The reason I'm asking is because I'm studying like crazy for my CLD and this is a very important point for me.
Thanks!
I know that this thread is old but I had these 2 comments on my CLD exam comments sheet and also didn't understand them! It would be nice for some amplication as to what the examiners mean.
I had "Non default used on typedefined cluster constants". As i took the exam a year ago I can't remember the instance that i used cluster constants but think that the following code snippet could be a likely no-no but would appreciate some feedback as I used this approach often when planning my CLD practice code:
To queue the next state transition I modify the constant to the the required state and bundle in the variant data which saves time and block diagram space in not having to bundle both items - is this okay?
I have played with modifying the cluster type def and it doesn't change the constant that i placed in the code snippet.
Helen
@HelenC wrote:
I know that this thread is old but I had these 2 comments on my CLD exam comments sheet and also didn't understand them! It would be nice for some amplication as to what the examiners mean.
I had "Non default used on typedefined cluster constants". As i took the exam a year ago I can't remember the instance that i used cluster constants but think that the following code snippet could be a likely no-no but would appreciate some feedback as I used this approach often when planning my CLD practice code:
To queue the next state transition I modify the constant to the the required state and bundle in the variant data which saves time and block diagram space in not having to bundle both items - is this okay?
I have played with modifying the cluster type def and it doesn't change the constant that i placed in the code snippet.
Helen
I admit, I do this all the time. Only change what you have to in the cluster just makes sense to me. I want to say there is a situation where if you change the definition of your type def then all of your constants will go back to their default. I wasn't able to make it happen just now. Will need to play more to see if I can get it to happen. Maybe it was only with Strict Type Defs...
@HelenC wrote:
I know that this thread is old but I had these 2 comments on my CLD exam comments sheet and also didn't understand them! It would be nice for some amplication as to what the examiners mean.
I had "Non default used on typedefined cluster constants". As i took the exam a year ago I can't remember the instance that i used cluster constants but think that the following code snippet could be a likely no-no but would appreciate some feedback as I used this approach often when planning my CLD practice code:
To queue the next state transition I modify the constant to the the required state and bundle in the variant data which saves time and block diagram space in not having to bundle both items - is this okay?
I have played with modifying the cluster type def and it doesn't change the constant that i placed in the code snippet.
Helen
I'm with Tim on this. Not a point I would mind losing.
That being said, Comment those not default cluster constants! When some text-coding JAVA weinee comes around and changes your enum type def that comment will save you a few handfuls of hair.
@crossrulz wrote:
@HelenC wrote:
I know that this thread is old but I had these 2 comments on my CLD exam comments sheet and also didn't understand them! It would be nice for some amplication as to what the examiners mean.
I had "Non default used on typedefined cluster constants". As i took the exam a year ago I can't remember the instance that i used cluster constants but think that the following code snippet could be a likely no-no but would appreciate some feedback as I used this approach often when planning my CLD practice code:
To queue the next state transition I modify the constant to the the required state and bundle in the variant data which saves time and block diagram space in not having to bundle both items - is this okay?
I have played with modifying the cluster type def and it doesn't change the constant that i placed in the code snippet.
Helen
I admit, I do this all the time. Only change what you have to in the cluster just makes sense to me. I want to say there is a situation where if you change the definition of your type def then all of your constants will go back to their default. I wasn't able to make it happen just now. Will need to play more to see if I can get it to happen. Maybe it was only with Strict Type Defs...
It might be if you add items in a place other than the end. I know that will hose everything up.
billko wrote:It might be if you add items in a place other than the end. I know that will hose everything up.
Yep. That was it. I added to a type def cluster and set the new item to be first and it set all of the constants to default.
EDIT: It is actually just reordering the cluster that causes the constant values to be reset.
