LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

ERD for LabVIEW flow

My boss wants to convert a LabVIEW program into another language and the programmers would like more than the flowchart I made and instead prefer an ERD diagram. From what I briefly gathered about these diagrams I'm not sure it can directly be applied to a LabVIEW program.

 

Has anyone tried to create an ERD for a program? I'm not sure how to even approach the 4 while loops in parallel.

0 Kudos
Message 1 of 8
(1,085 Views)

My understanding is that ERD is for Database and LabVIEW is a programming language and not a database to convert into one such.

 

Maybe, they are looking for an algorithm or pseudocode?

In terms of converting LabVIEW source into some other language, the programmer must be proficient in both to create an equivalent but it does not mean it will be the same as each language has its own pros and cons and you've to work your way around it.

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 2 of 8
(1,064 Views)

I agree that they should probably start from scratch giving all requirement. ERD shows relationships (not dependencies or flow) and is not suitable to describe a LabVIEW program, or any program in any programming language.

 

What's the reason? Is the LabVIEW program not working right? Seems like a huge waste of manpower to reinvent the wheel.

0 Kudos
Message 3 of 8
(1,048 Views)

Exactly, the videos I saw on ERD always started with someone explaining an ERD for a database...

 

You guys are kind of confirming what I've been trying to convey in that its not 1 for 1 between say LabVIEW to another language. The best I can do is explain how it works in LabVIEW with flowcharts, algorithms and pseudocode plus any calculations made.

 

As to why they're trying to convert from LabVIEW, my guess is their team is all C++/.net programmers and they want to be able to make changes in that language. I'd say the program is actually written very well in LabVIEW too. 

0 Kudos
Message 4 of 8
(1,030 Views)

@PatrickMiller wrote:

Exactly, the videos I saw on ERD always started with someone explaining an ERD for a database...

 

You guys are kind of confirming what I've been trying to convey in that its not 1 for 1 between say LabVIEW to another language. The best I can do is explain how it works in LabVIEW with flowcharts, algorithms and pseudocode plus any calculations made.

 

As to why they're trying to convert from LabVIEW, my guess is their team is all C++/.net programmers and they want to be able to make changes in that language. I'd say the program is actually written very well in LabVIEW too. 


 

It is not that easy to find good C++/.NET programmers that are electrical engineers and understand the hardware.

If your bosses are thinking that computer science majors are going to do this better, then they will have a rude awakening.

This request for ERD request sounds like the typical CS stuff.

 

I once interviewed for a job where the main test program that they wanted me to work on was written by a CS major with background in writing software for the financial world.  That CS major bolted back to financial world after 6 months on the job.

.

0 Kudos
Message 5 of 8
(1,013 Views)

@PatrickMiller wrote:

Exactly, the videos I saw on ERD always started with someone explaining an ERD for a database...

 

You guys are kind of confirming what I've been trying to convey in that its not 1 for 1 between say LabVIEW to another language. The best I can do is explain how it works in LabVIEW with flowcharts, algorithms and pseudocode plus any calculations made.

 

As to why they're trying to convert from LabVIEW, my guess is their team is all C++/.net programmers and they want to be able to make changes in that language. I'd say the program is actually written very well in LabVIEW too. 


Definitely not a trivial task. This is just the same as developing the application from the ground up in the new language of choice from requirements (discard what the existing LabVIEW application is capable of). As PatrickMiller pointed out if the C++/.NET developers are pure software guys who could not comprehend all the electrical/test instrumentation knowledge, that increases the complexity by an order of magnitude (moreover you need someone to point them to what instrument APIs to use and how to use and even debug with them).

Santhosh
Soliton Technologies

New to the forum? Please read community guidelines and how to ask smart questions

Only two ways to appreciate someone who spent their free time to reply/answer your question - give them Kudos or mark their reply as the answer/solution.

Finding it hard to source NI hardware? Try NI Trading Post
0 Kudos
Message 6 of 8
(999 Views)

This sounds like something got lost in translation. Assuming that the switch is over to object oriented programming, it will help immensely to have a chart of entities and how they relate to each other. If you did not use OOP in LabVIEW already, identifying the entities may not be immediately obvious, so that is the tricky part.

 

In Computer Science, there seems to be consensus that flowcharts are not a good way to communicate logic and it is better to communicate the data structures. A famous quote goes "Show me your tables, and I won't usually need your flowchart; it'll be obvious." (Fred Brooks, The Mythical Man-Month). "Tables" here refers to the data description. For some meditations on this, check out this SE discussion.

 

In non-OOP-LabVIEW, this structure is commonly hidden away, but can be found if you know what to look for. If you used some kind of consumer/producer framework, check out the main loops. All data going through the loop, especially in shift registers, is either part of an entity, or it is being acted upon by the entity. The messages or cases in the case structure are the functions of these entities. If you sorted the data into clusters, your work is mostly done already - look for code that uses information of one cluster to act on itself or another cluster. The clusters are your entities and the "acting on" code is the relationship. This should work for most of the while-loops in your code. If you have Action Engines/FGVs or the like, these are pretty much your entities right there. You can even call them "Singletons" if you want to impress your OOP-colleagues.

Message 7 of 8
(960 Views)

@PatrickMiller wrote:

My boss wants to convert a LabVIEW program into another language and the programmers would like more than the flowchart I made and instead prefer an ERD diagram. From what I briefly gathered about these diagrams I'm not sure it can directly be applied to a LabVIEW program.

 

Has anyone tried to create an ERD for a program? I'm not sure how to even approach the 4 while loops in parallel.


By the way, this type of event is a red flag in my book.

Is LabVIEW widely used in your company?

If not, you may be helping to eliminate your own job.

Keep that resume updated.

 

 

0 Kudos
Message 8 of 8
(940 Views)