Export Sequences

[RodSwan]

Hi,

I'm sure I can't be alone in this need:

I'd like to be able export All sequence code (including buried quick sequence code if possible) to a simple ascii text file to allow documentation of drawings and easier comparison of similar drawings.

Current project I am working on, initially created by a third party, has over 6000 lines of code which has to be documented so it can be maintained by more than one person. It is all to easy to make apparently innocuous changes that are difficult to find and document.

Exporting all to a simple text file (in a consistent format) would allow simple text comparison utilities to identify changes.

[BallardHill]

I strongly second this feature request!

I've developed hardware and software, much of it embedded, for over forty years, and the most reliable and respected development products have all offered some native or third-party methods of managing code versioning, documentation, and analysis.

DAQFactory's current functionality is far ahead of any existing similar systems and would be made even more valuable in the marketplace by more formal software development tools such as the above-mentioned.

Perhaps an add-on sub-product could be offered so those not needing or wanting the functionality enhancements would not be forced to subsidize its cost, but those of us creating complex implementations, or even more compelling, inheriting legacy DF systems, could manage our work in a more formal and professional manner.

I'd suggest a bridge between the .CTL file and some existing code-management library or tightly-integratable application to maximize AzeoTech's ROI for a very valuable enhancement to your product line offerings.

Perhaps integration(s) with FOSS code could maximize development management resources while affording AzeoTech the minimum-development-effort path.

[angus.morgan]

Referring to my previous post (http://www.azeotech.com/board/index.php?showtopic=4442), I strongly agree with both previous posters.

[andrewjfox]

Yes!

Although I am very happy with DF and it's my go-to solution in most cases, this feature is sadly lacking. Being able to document all sequence code, including quick sequences, would also allow better searching for all variable and function usage throughout a ctl document, rather than just current sequence (I would prefer the built-in search had this capability).

Regards

Andrew

[RodSwan]

Any movement on this?

It really is a pain to have to duplicate every change into a seperate text file to maintain a searchable version history.

After 6 years of development and now at version 10.06.06.i (10,000+ lines of code, 12 sites and growing) it would be impossible to maintain without documentation so it has to be done manually - inevitably this leads to mistakes and loss of synchronisation between the documentation and the CTL file requiring regular (and lengthy) manual process to re synchronise them.

Rod.

[AzeoTech]

It is still in the works. However, there is a way to do it using the existing DAQFactory, though it requires you to put everything in classes, something that you really should be doing anyway if your code is 10,000 lines! There is plenty of other posts about classes, so I'll assume you know how to create them. So what you do is you put your class declarations in external text files. Then in DAQFactory you have a rather short script that loads the text file in, and does execute() on the contents. Normally execute is designed for just running a single line macro, something like:

private chanNum = 2

execute("myChannel" + chanNum + ".addValue(4)")

However, execute() simply passes the string to the compiler and then runs the result (if no errors). Since a class declaration doesn't actually do anything but create the class template, you can execute() it and all it does it put all those associated functions in memory. Then, in a normal sequence you can instantiate those classes. In fact, you can design it so you just have to instantiate one class, and then that object does the rest. If you rerun the loading code, it will update the template.

Pros:

1) you can put almost all your script in text files, which you can then run through your favorite source code control tool

2) you can actually create multiple text files if you want. Load and execute them all, and then instantiate.

Cons:

1) you aren't going to be able to step through your code, and you are likely going to get error messages with weird line number specifications. I haven't looked, so it might just be like other member function errors which would be better. You can use standard embedded system debugging tools to help you (i.e. lots of ? statements, which, by the way you can disable in bulk setting the system.sequencePrint variable to 0.

2) there is a bit of a security issue here, since your distributed code would be open and exposed in text files. You could however protect the code. The best way would be to run encryption on it. I can't talk details of encryption, but many encryption algorithms are pretty easy to script in DAQFactory. I recommend scripting both sides, meaning, use DAQFactory to both encrypt and decrypt the code.

3) if you don't want to do encryption, but you still want to make sure someone doesn't mess with your code, or in addition to encryption, consider including a checksum. Again, there are lots of ways to do a checksum with algortithms available on the net. Personally, I would consider writing maybe 1000 random bytes to the header of the file, then a 4 byte checksum, then another 1000 or so random bytes so the location of the checksum is not obvious.

Note for #2 + 3, you would do this only for distribution. You'd have to have some sort of script to convert your script files into an encrypted or checksumed file. You should probably concat the files at the same time to make distribution easier.

[SteveMyres]

Another +1 on this request.

[RodSwan]

Gosh... That method described by guru is a major crash waiting to happen.

The amount of extra work to create/debug/use that technique is a minefield waiting for new problems to be introduced!

Definitely not workable!

All I need is a simple command on the menus that will traverse through all sequences (and quick sequences everywhere) and list them to an ascii file... of course some indication the details of the sequence, like priority, Name, where to find the sequence in the drawing if its a Quick sequence.

The listing doesn't need to be readable back into Daqfactory (though it would be nice but I guess pretty difficult for the quick sequences).

It just needs to be a complete ascii listing of all sequences.

Possibly include the channel table as well.

Sure it can't be that difficult to do???? (probably a lot easier to write than the Kludge suggest above!)

Rod.

[AzeoTech]

Yeah, I wasn't actually really suggesting someone use my technique, more just trying to open up more advanced user's eyes to what is possible.

The hard part with what you describe is that things like quick sequences have no real identifier. DAQFactory doesn't force you to name every component, so how would you tell which quick sequence went with which component? Also what you describe is a partial fix and doesn't help people that want to use scc tools. We'd rather concentrate on providing a proper solution, which we are actually working hard on right now.

[SteveMyres]

For quick sequences, use page name plus coordinates of the containing object. In fact, do that even for named components. Just the name doesn't tell the person where to find it, especially if he's not the original developer.

That method seems to be the standard in HMI's that I've used.

[SteveMyres]

Another thing many programs do is to automatically name each component with a unique default name, like "Button38". You could still allow the user to change the name if desired, but every quick sequence would be in a named component. You should still include coordinates, or if you go to everything having names, you could instead have a means for listing coordinates for any given component name.

[AzeoTech]

We'll probably be using the second approach, naming all components when they are created, but allowing the user to rename it. As for coordinates, that ideally won't be necessary. We'd like to make it so the components are listed, probably in the workspace under the page, so clicking on it will select the component. Having the user try and figure out what component is referenced by coordinates is very antiquated.

[SteveMyres]

I agree, that sounds like a better approach.

[RodSwan]

However at this point, there is no way to tell if any changes have been made to any of the sequences wherever they be - whether deliberate or accidental. I often find that changes made "in passing" or in haste to resolve live problems get forgotten about and carefully maintained ascii file copies of the sequences (purely for SCC) get out of step with the CTL file.

Only way to re-synchronize is a painstaking troll through the CTL file, hoping we don't miss any of the quick sequences.

My introduction to DaqFactory was to make a large CTL file work - it had over 6000 lines of sequence code... a lot of it as quick sequences on components that were either hidden behind others or just plain not visible. It to me months to find them all. A simple listing, no matter how archaic would have save months of work.

As for not helping with the SCC fraternity - for my part it would do exactly what we need: It wouldgive uas the abilty to store a traceble log of what changes are made to any of the sequences - Automatically.

Sequence names, of simple coordinates (page name and x,y position) may be "antiquated" (Really??? I thought that was what computers use!) but they work and are a damn sight better that nothing (i.e. what we have now).

Please re-consider.

Rod.

[AzeoTech]

Trust me. This is a priority and I hope you didn't get the wrong impression. However, we want to do it right the first time.

[AzeoTech]

That said, a simple sequence dump would not be hard to add and would not send us down any wrong paths. It would be a simple dump to a flat file, or perhaps maybe the option to multiple files. No import, so you'd have to do the edits within DAQFactory. But at least you could do global search, and use SCC for some basic maintenance. I'll check and see what is involved. Rod, please email support@ and request to be on the beta list (if you aren't already) if you'd like to try it. We'll still work on the ideal solution, but this would be something.

[AzeoTech]

OK, it is done and will be available for beta shortly. Rod, please contact us (email support@) to learn how to become a beta tester. I look forward to your feedback on the feature.

[RodSwan]

Ok, Ta.... Will Do.

Rod.

[SteveMyres]

In the beta version of the script dump feature (before default names and the tree list), an entry for a button, for example, would be of the form

 

Page.Main.XxxxYyyy.QuickSequence_0

 

Now with automatic default naming, it's

 

Page.Main._Button.QuickSequence_0

 

This does two things that are undesirable from my point of view:  (1) the list under the workspace entry for the page contains a large number of indistinguishable _Button and _Panel entries and so on and (2) since the dumped list is sorted alphabetically, it groups all the _Button QS_0's together and all the QS_1's and so on, rather than all the QS for a given button, then the ones for the next button and so on.  The beta version that included the coordinates was more helpful in keeping the components separate since they were uniquely ID'd and sorted together.  If the objects all had unique names, either by keeping the coordinates, or by generating unique default names like _Button12 and so on, or both, then the script dump would keep actions associated with the same component grouped together and the tree list would have entries corresponding to the dump, which would be preferable.   Having existing components from old development show up with generic names would be fairly manageable if new elements got auto-generated unique names; you'd just have to go around and name all the old elements. For new development, since the names become more pivotal, it seems like the auto-names should be unique or you should include the coordinates or both.

 

Also, and I can't remember if it's been this way since the release of 5.90 or not, but if you click on an entry in the list, DF selects the component, but doesn't leave the workspace entry highlighted.  It might be preferable to leave the tree entry highlighted, which would allow you to arrow up and down through the list.  OTOH, that would require another keystroke or mouse click or something to begin editing that component, so you'd have to balance that.  So not sure what the "right" answer is on this one, just reporting that after clicking on something in the tree list, my instinct is to assume it's still highlighted and start arrowing up and down the list.

[SteveMyres]

A bit of quick feedback to tell you how VASTLY helpful this feature is, even without the tweaks requested above.

 

Makes managing (snapshotting, searching, reviewing, etc.) the sequence code in an application so easy.

 

Thank you!

[RodSwan]

Hi,

As Steve Myres commented above... this has made an immeasurable improvement in the management of my various Daqfactory projects.

However one small change (I'm sure it would be a simple change) that would make another big improvement would be to include the priority of each sequence at the head of each listing (just after the sequence name would be nice).

 

I have been burnt so many times by a "feature" of Daqfactory that is difficult to get a handle on at the moment... When debugging code and single stepping through sequences I mostly use the mouse wheel to scroll through the code I am debugging, but when a breakpoint is hit and execution pauses, using the scroll wheel changes the priority of the sequence by default.

I can't count how many times I've done that and I don't know how many times I've done it without spotting it. With hundreds of sequences it is VERY time consuming to check each one individually.

 

If the sequence priority was included in the listings, a simple compare would highlight any changes.

 

PLEASE PLEASE PLEASE can you add this?

 

Rod.

[AzeoTech]

I think a better choice is to simply make it so thread priority is changed in a sequence in a different way so you don't accidently do this.  I don't know if you reported it elsewhere, but I remember someone saying they had the same sort of issue recently.  Anyhow, we could make it so you click a button and then a popup appears to select the priority.  It would also allow us to provide a bit more explanation right there.

[RodSwan]

I can't dispute that changing the way the priority is set would resolve that particular problem (it was ccdubs that made similar comments on 24th May) but wouldn't the amount of work for you guys to change that (and all the documentation/screen shots etc) be significantly more than that to add a single line of text to the script dump output and therefore be more likely to get a result?

 

It would also give a more complete "dump" of the Sequences that can be automatically source code managed (you know - same justification as for the original Sequence Dump Request). And, of course, we could then scan the dump file quickly to verify all the priorities are correct rather than having to "edit" each on on screen - which you have to mouse click on each sequence in the Workspace tree to do, up and down arrow on thekey select each sequence in turn but doesn't bring it into the editor so you can see its priority - and the priority is also sadly missing on the Swquence summary page where a quick visual check on each one could be done. Putting it in the dump file has to be the answer! (Please)

 

Sorry to keep on, but it would be very useful.

 

Rod.

[AzeoTech]

The best choice then is to do both!

[RodSwan]

I think the addition to the dump file should be a 5 minute upgrade as most of the code must already be in place  (Don't get me wrong - I don't know any of the internals of DAQFactory, so am not in a position to make such claim).

Also, it shouldn't impact on anybody else. 

Jiggling with the UI is always going to be a pain and whatever you do with it, it'll never be right for everyone. Someone is bound to complain if you change it :-(

 

Of course, you're not called the guru for no reason, so the choice is yours :-).

 

I just look forward to the extra bit in the dump file!!

 

Many thanks

Rod.