Add 'duplicate frame' to the flat sequence context menu

[sbus]

When building a case structure, the context menu allows you to 'add case after', 'add case before', and 'duplicate case'. This last option ('duplicate case')can save huge amounts of effort in cutting and pasting or re-entering your block diagram.

Unfortunately, these options are not available when entering a flat sequence. Flat sequences do not offer 'duplicate frame', a major omission and also another example of where LabVIEW is inconsistently implemented..

I for one would dearly like the 'duplicate frame' option added to the flat sequence context menu.

[altenbach]

That makes little sense to me, but maybe I don't fully understand what you have in mind.

There are no quarantees that a frame has matching inputs and outputs, so I don't see how things should "mesh" in the general case when duplicating. (Cases and events don't have that problem).

Also, sequences are rarely needed in a well written program. If two consecutive frames should be the same, use one instance of the content in a FOR loop instead, right? Why would you want to duplicate the code??

[sbus]

The idea is that the frame is DUPLICATED; if things don't 'mesh up' then they show as not being connected correctly. This idea is only to make it easier to enter code, and has nothing to do with final functionality. My assumptions is that after duplicating the frame you're going to edit it to make it different - but potentially saving a lot of work.

We have code that executes a GPIB command in each frame of an event structure. It's a pain-in-the-ass to have to control-drag code over and over again, then just edit some parameters.

[Dennis_Knutson]

Why would you ever need to place GPIB commands in a sequence structure? You have the error in/out as well as the VISA Resource Name/VISA Resource Name Out to enforce dataflow.

[sbus]

Dennis -

This discussion is about adding a feature to the Labview user interface to make it easier to do some things that SOME users would like.

The real issue is whether adding the ability to duplicate a frame in a sequence structure when editing your Labview code is useful. What I use the flat sequence for is irrelevant to the discussion.

FYI, I don't use VISA.

[Dennis_Knutson]

I understand what the discussion is about and since we don't have the equivalent of a negative kudo, comments like mine are the only way to say to NI that I would not want NI to spend any time pursuing this idea. The use or non-use of the sequence structure is absolutely relevant.

I won't comment on what I think about not using VISA. That has no bearing on your original idea.

[AristosQueue (NI)]

> a major omission and also another example of where LabVIEW is inconsistently implemented..

It was a deliberate omission. The flat sequence is not a stacked sequence. When duplicating a stacked sequence frame, the inputs of the new frame always align with the inputs of the previous, and the same for the outputs. With a flat sequence, there's a near certainty that the left side tunnels are not identical (type and vertical position) to the right side tunnels. To support Duplicate Frame on the flat sequence we would have to define some system for handling that discontinuity. Just about anything you can propose has some weirdness in common cases. Going the extra distance to support this feature seemed wasteful since copying code is something we want to generally discourage anyway.

[sbus]

Dennis - just a note about not using IVI. We are using extremely old GPIB equipment. It is NOT compliant with the IEE488 spec, or the 488.2 spec. It has timing issues as it does not correctly handshake. The company that made it is out of business. We had to hand-tune delays in the code to get the equipment to function consistently. The original DOS application that controls the equipment is circa 1983. When I rewrote the app into Labview I had to make it work with the old suite of equipment. I had to implement a send-gpib-cmd and recv-gpib-data function in Labview that would handle the often bizarre timing issues associated with these instruments. VISA didn't allow me to access the primitives. In addition, there are not VISA drivers for this equpment. I now have a single Labview routine that correctly addresses the hardware. In addition, we use both the old and newer equipment for final QA testing of microwave filters. We deal with the military and produce MIL and space qualified filters. Absolute traceability of testing is a requirement. Having routines like 'initialize instrument' that are provided with a VISA driver and are opaque don't help us - we want and need absolute control over every bit sent and received between our application and the test equipment. I don't use VISA because I need to know *exactly* everything that transpires between my application and the equipment it controls, and because I have to both deliver and defend every scrap of code that is involved.

Aristos - I understand why NI doesn't want to implement the user-interface feature that would allow Duplicate Frame in a flat sequence. However I disagree with the idea that there even should be a requirement that things 'line up' when you duplicate a frame in a flat sequence. If the tunnels don't line up, then don't make them the same tunnels. Assume that the user who duplicated the frame did it for a reason - and that they will solve the discontinuities themself by editing the frame to correct those discontinuities. Also, the comment about 'discouraging copying code' is interesting since Labview includes cut-and-paste (which, by the way is a pain in the ass because there doesn't seem to be a way to restrict where the pasted code goes - I frequently have to search through my block diagram to find pieces of the pasted code that are far away). This isn't a major issue to me, just an inconvenience; it'd be nice, but...

[G-Money]

I agree with Aristos that implementing the tunnels for duplicating a flat sequence structure compared to a case structure would be really different for R&D developers. There would need to be a lot of logic needed to take place just to give estimate of what needed to be copied and then allow the user to figure out what needs to be cleaned up. I think it would be interesting though to be able to copy any frame within a sequence of frames and then paste that as a new frame (right-click on a frame and Copy, then Ctrl+V somewhere on the Block Diagram and a new single frame would get created). This would only require looking at the code and the existing tunnels of that single frame to create a new seperate instance of a that single frame. You could then add that into the dataflow by wiring things together and control the order in which the frames are run. I'm interested to see how many other LabVIEW developers out there would find this feature yourself. I'm sure they are out there and hopefully they will find you idea and kudos it if they agree.

[Darin.K]

Right now you can replace the Flat SS with a Stacked SS, duplicate the frame, then replace again with a FSS.  No more often than this would or should be done, that seems sufficient.  I suppose NI could provide a right-click option to speed the process, but I wouldn't spend much time refining the results.  I am pretty certain it is a train wreck in most cases.

[sbus]

I also have a separate thread going suggesting the ability to join/split flat sequences. The idea of using cut/paste to copy a frame from a flat sequence coupled with the join/split functionality would accomplish everything I'd like to see.

The split funcitionality would split the sequence on a frame boundary into two sequences wired together. The joing functionality would join two sequence on their adjacent frame edges together into one if they were wired together.