LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

wire things faster

Solved!
Go to solution

Nah, don't mark mine as the solution.  It was mentioned before my post.  Maye a kudo for being on the right track, but not as the solution.  (There were other good suggestions also and you can actually have multiple solutions marked.)

Bill
CLD
(Mid-Level minion.)
My support system ensures that I don't look totally incompetent.
Proud to say that I've progressed beyond knowing just enough to be dangerous. I now know enough to know that I have no clue about anything at all.
Humble author of the CLAD Nugget.
0 Kudos
Message 11 of 20
(1,096 Views)

This simply doesn't work I have a huge block diagram of simple state machine, I've tried to do this to save me time but I think is even worse, simply locks my tool in wire and it doesn't let me move freely through the diagram, I have very hard time, spent hours to wire my diagram.

0 Kudos
Message 12 of 20
(696 Views)

@jalex0906 wrote:

I have a huge block diagram of simple state machine...


A simple State Machine should not have a HUGE Sequence Structure in it.  You might want to consider setting each of those frames into their own state.  You should also consider turning some of the larger chunks into subVIs to shrink down your diagram.

 


@jalex0906 wrote:

I've tried to do this to save me time but I think is even worse


What are you referring to as "this"?  If you are referring to the Linked Tunnels, you just have to get them set up once and it is ready to go for any cases you add.  I never had issues with them, even in my larger VIs.


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
0 Kudos
Message 13 of 20
(690 Views)

@jalex0906 wrote:

... I have a huge block diagram of simple state machine ....

 

That's the first problem.  You should need a huge block diagram for a simple state machine.   Looking at your picture, you have a flat sequence structure inside your "Prueba" state.  I bet some of those frames could be combined.  And if there needs to be a distinct separation between those frames, then they should be in their own states.  Some of them look like they belong in an initialization state.

 

How many screens wide is your VI?  Do you have the Navigation Window open?  I find that for the larger the VI, having the navigation screen open will cause screen refreshes and scrolling to be slower and slower.  Every move of the block diagram on screen causes the need for LabVIEW to recalculate and refresh the way the navigation window shows the entire block diagram.  Closing it will cause an immediate speed up in block diagram scrolling speed.

 


@jalex0906 wrote:

This simply doesn't work ... I've tried to do this to save me time but I think is even worse, simply locks my tool in wire and it doesn't let me move freely through the diagram, I have very hard time, spent hours to wire my diagram.


What exactly is "this" you are referring to in the thread?  What does "simply locks my tool in wire" mean?

0 Kudos
Message 14 of 20
(689 Views)

resurrecting a 4 your old post just to complain about your poorly structured code?

If you have a "STATE MACHINE" why-oh-why do you have a sequence structure?

 

BTW. The "locked wire tool" is LabVIEW asking which tunnels to link together.

edit: Wow I was really slow. LOL

---------------------------------------------
Certified LabVIEW Developer (CLD)
There are two ways to tell somebody thanks: Kudos and Marked Solutions
0 Kudos
Message 15 of 20
(688 Views)

Your VI is simply too big to edit properly.  As others have mentioned, get rid of the sequence structure and either move those frames to your main state machine or create a new state machine(s) inside your main state machine to handle specific tasks. 

 

A trick I use when I know I'll be adding new cases is to create a dummy case that just has all the shift registers wired across.  Then when I need a new state, I duplicate the dummy and it's already wired.  I will even add some extra shift registers at the bottom that do nothing.  If I need a new one later I just drag it up and use it.  Its already wired through every case.  Smiley Wink

LabVIEW Pro Dev & Measurement Studio Pro (VS Pro) 2019 - Unfortunately now moving back to C#, .NET, Python due to forced change to subscription model by NI. 8^{
0 Kudos
Message 16 of 20
(674 Views)

Hi RavensFan thank you for your response, Yeah for sure I need to make a state for every code contained in the flat sequence structure, the problem here is what happens if it still being to big?

0 Kudos
Message 17 of 20
(631 Views)

Hello NIquist:

 

Thank you for your tips I'm on it...for sure it will work, however I still having doubt about what wil happen if my code still to big.

 

Greetings From Mexico

0 Kudos
Message 18 of 20
(622 Views)

A block diagram being too big isn't going to affect how well your code executes.  But code that is too big that you can't functionally maneuver in it, or understand what is going on, or be able to make the inevitable changes to it when someone asks to have a new feature added, means it is impossible to maintain and risks breaking if you try to change something.

 

If you still have problems working with your code when it is still too big after re-working it, then it means you still have a lot more rework to do, or need to scrap it all and rethink your overall architecture.

 

PS:  My message 14 should have said "You should NOT need a huge block diagram for a simple state machine."

0 Kudos
Message 19 of 20
(620 Views)

@RavensFan wrote:

A block diagram being too big isn't going to affect how well your code executes. 


Actually, it does. If the complexity is very high, the compiler will skip some optimizations to save compile time, resulting in less efficient code overall.

0 Kudos
Message 20 of 20
(610 Views)