No flaming but I do remember different companies trying something like you are suggesting by using GUI and building blocks that you drag and drop. Don't know what happened to those companies.

In a way, that is what the majority of functions in ARC are doing. Particularly frames and actions.

Scripting is the advanced add-on on top of the basic drag and drop functions available in ARC.

I am not saying your idea is bad. Just to do it, beyond what the UI already does, would be a massive undertaking. The scripting language is really not that hard to learn, and the community is always here to point you to existing scripts or help you write scripts when you need it.

Alan

Lego Mindstorms (first version anyway) and Parallax's scribble bot use that visual flowchart style programming... It is handy to see your code in a flowchart to visually see how it is working...

@Richard R I sent you an email bro...

I use a flowchart system on everything...simply so I don't get confused when there's too many things going on, and it's easy to get lost. Nice to have a map of functions.

@Marc... email sent...

I saw an Arduino flow chart GUI system, it sucked.

How's this for a system, create a flow chart, post it here and let a real person code it properly?

Honestly, I am always looking for something to write but am always out of ideas. All of my scripts which I have shared and improved are based on someone else's idea. Ping Roam was based on someone else's question posted. Speed ramping was built on someone else's question. Speak The Time/Speak The News built from someone else's question or script.

Truth is, I love to write scripts so feed me ideas The flow chart would be a great help. Sure it's not an instant solution but it would provide much more modular, better formatted code which can be used to learn, teach and explain.

I know it's a little hidden in the script section but ARC does have a Script flow feature. I believe it kinda works backward to what @jay is looking for though, you write the script and the script flow will show you a flow chart of your logic.

Thx guys great input !

Nowadays visual programming tools combine both control and data flow into kind of event driven programs with implicit events. If you ever coded event driven apps, like for Windows or other GUI's, then you know how hard it is to figure out what's going on at runtime, even more inside a robot with sensors firing without close relationship to the control flow. I was really impressed when I found out how much visual programming can help in such a scenario :-)

Learning to have a good code structure layout can mean the world towards understanding your code's paths and making troubleshooting easier on yourself. In my line of work we have block diagrams that show flow or we have a set of requirements that state how the code should work. As a firmware engineer, I would much rather have a set of requirements than a flow chart to work from.

@orwnic82 Which type of "firmware" do you mean - embedded or low level code, libraries...? High level application specific languages deserve a lower level framework, i.e. kind of an OS and libraries, with different development requirements in each area.

But I don't see a big difference in flow charts, state diagrams, and other forms of requirements, as means for the description of the goals. That's independent from the implementation, where different techniques may suit better. In either case the verification of a professional implementation requires that each party can determine or demonstrate that and how the goals are reached. This suggests to me some formal layer on top of an implementation, understandable by both the ordering party and the contractor. I.e. they should speak the same "language", be strict or sloppy, textual or graphical. Even if the same person defines and implements her application, she should have such a choice.

@dodi

I am not saying anything against either method, just my preference. I'm also just saying that if he manages his code correctly then he should be able to recognize the paths it flows through and anyone else should be able to apprehend it.

I mostly program in vhdl now. I have dealt with programming ADA and assembly a couple of times but that's mainly on older systems. When it comes to mapping code in assembly that's a whole different story cause those instructions are specific register moves. So I am not really trying to bring that up as reference to the current topic.