With my industrial background as PLC programmer in FBD (Function Block Diagram), I jump up to XOD as a kid on a pie. But I miss some common and universal blocks here.
What I miss the most now after 2h of using XOD are memory flaggs.
I’ll put in a screenshot of what it is, and a second of why you/we need it in XOD.
Ahaa! You call them “memory flags.” We have thought about a similar mechanism, just named them “portals” or “buses”… doesn’t matter.
The point of dispute is whether it helps more than hurts. Personally, I incline to the former. But there’s an opposite point of view: such a mechanism could potentially encourage many implicit links, so many that it will make virtually any patches more complex than trivial hard to perceive and understand.
I’d love to hear what other xoders think on this topic: are such teleports/flags/buses (whatever they are called) is a desirable and useful feature?
The example I give in “screenshot 2” is just a small one. A small dayly one on a project that is stuck because of a missing function that is one of the basics of all electronics. I can give you 20 simple common programms like this that can not be made without a flag (marker is the official therm btw) in a minute…
If you want to make a robot or complex programm other than blinking a LED, you’re done.
I work with PLC’s every day, and have never seen a build platform without flags.
gweimer; A defer-pulse yes and no.
Yes: for a only one blinking LED in a programm, a defer pulse can be a solution.
No: when you have a project with more than 5 blocks, it does not work. I made the simpelest programm here, and the defer-puls already stops working.
Markers/flags help to make your program clean, structural, and most of all logical.
It reduces the number of lines and connections, and it helps people who don’t wrote the program what is going on. For example, when you are working with two engineers in 1 project, markers make it possible to fragmentate complex structures in to easy to read pieces.
If your intention is to reset the counters with the reset button, you will need the defer-pulse linked to the reset rather than flip-flop. The button changes the flip-flop to 0 (reset), so it is not sending a pulse to reset counters when the reset button is pressed (unless it is pulsing on false instead of true, which would mean it doesn’t pulse when 2nd counter >9). [edit: I guess you would need an any node to link flip-flop & reset to the defer-pulse to reset on either condition.]
Unless I’m missing something, using the flip-flop will cause both counters to reset when 2nd counter >9 the 1st time, but if reset button is not pressed, it might not cause a reset the next time 2nd counter >9 because the flip-flop is already true, so output value doesn’t change, so there is no pulse (I could be wrong if SET explicitly sets the value & XOD treats this as a “change” even though it is “changing” from true to true).
Maybe this is your desired functionality, and I’m just stating the obvious to you…
As a side note, it would certainly make for cleaner graphs if there was a defer-pulse option that was implemented using 2 nodes; one for input that would usually be lower in the graph and one for output that would usually be higher in the graph (or might be on different sides of the graph). It would have the same functionality, but eliminate the line cutting back through the middle of the graph. There would have to be some way to designate which 2 nodes were a pair (maybe a hidden link that appears when you select either node & one label shared by both nodes?)…
I’m not sure how markers/flags would be any different than defer nodes… Do markers/flags do more than indicate that “this” output ties back to “that” input?
Start with a single node with a gripper on the left (top & bottom corners?) so the node can be “torn” in two. Both parts would be treated as a single node. Both would have the same label. A link between them would be shown when either is selected, but be hidden if neither half was selected. Both “halves” could be displayed 3/4 tall if more space is needed for the label and a dotted line could be used for the torn edge. The two halves would be joined back into a single node if both halves are dragged to the same location. The gripper does not need to be displayed after the node is “torn” (but could be; it would just be another place to grab to move the node).
The end result is that this is just window-dressing. You change how you are displaying a single node to reduce lines cutting back through the graph, but it does not change how code is generated for the arduino.
I don’t know if it would make sense to allow this “tearing” on other nodes. Maybe the pulse-on-* nodes, but it probably should not be allowed for all nodes; especially not nodes with multiple input or output pins. Limiting to only defer-* nodes makes it more clear what is being done when labels are changed to make it clear which markers/flags are linked (they are all defer-*, so you don’t need to wonder if it is a pulse-on-change or something else and the pin type tells you which defer-* it is.). Maybe add a split-node directive similar to variadic-* to indicate which nodes can be torn? The down-side is I can see split-node becoming abused & as dreaded as the goto statement…
One mechanism to distribute the collaboration process is to create new patch nodes. You work on these patches, your colleagues work on that patches, etc… However, your PLC experience is valuable and interesting to hear. I am inclined to arrange flags/labels/portals/buses implementation because every day I see the cases where they can make program graphs much easier to understand.
@gweimer, thank you a lot again for sharing your mind. I liked the idea of tearing which is restricted to the defer nodes. I see some other scenarios beyond defers though:
A patch-global flip-flop which defines whether the current patch is active in some sense or not. Sets on input pulse, resets on output pulse, the value is required at many points.
An input config parameter (like I²C address) is required at many points
So, one possible solution could be adding a pair of nodes, say, bus-in / bus-out which have an outstanding look, say, a horizontal line segment. A user can change the label of a bus node. All bus nodes with the same nodes are considered to be interlinked. Buses with labels matching terminal labels are interlinked too. The implicit link could be materialized, as you have suggested, on selection or hover.
The bus is quite a bit different than the tear/split node since it allows multiple outputs. In that sense, bus would give more functionality. A bus/flag could be used to loop back to another part of the program like the split defer-pulse (you just need to add a defer-pulse also), and could be used to feed the output of a flip-flop to multiple locations without the confusing wires cutting across the graph.
I assume it would be an error to have a bus-out node with no same-named bus-in node and also to have more than one bus-in node with the same name.
If you don’t like the idea of using the node label to link the nodes, you could go back to the tearing idea, but if you can have multiple outputs, it means you are always tearing off the output part, which gives you a copy of the output (leaving the output on the original node to tear again). Since the input/output nodes are explicitly linked, you don’t have to worry about the error conditions listed above and changing the value or label of any linked node would change them all (or you could force the change to have to be made on the input node to change all the linked nodes; it seems like this would have less risk of accidentally changing a group of links & you shouldn’t be able to change the input value from the output node anyway).
This could still be implemented using a variadic type of flag on any node, but it probably makes more sense to have an explicit bus node with a unique appearance that only implements the functionality of linking a data value to other parts of the program with hidden wires.
How to do the gripper for “tearing”? If it is a horizontal node, you could show one input & multiple outputs from the horizontal pipe. The input and only one output would have a pin. Grabbing the other output without a pin would create a bus-out node linked to the original bus node for its input (also displayed as a horizontal pipe, but with no input and only one output with pin? Show multiple outputs so you can also tear from bus-out node & not just from original bus node? Multiple outputs for bus-out means it is same width as original node for displaying label.). The horizontal pipe would be a convenient place to display the node label.
If using the tearing idea with explicitly-linked nodes, it would have to be possible to delete a single bus-out node. Deleting the original bus node would have to delete all connected bus-out nodes also.
Again, two options: it can be an error or a no-op connection, i.e., a floating input. An explicit error should protect from typos though, I agree.
Regarding to multiple bus-ins, it definitely should be an error.
Agree, in that aspect tearing wins leaving no room for silly mistakes. Although I can’t imagine a user workflow in which the tearing apart of a bus-out is intuitive to learn and use.
Your thoughts help a lot and I’m sure we’ll come up with an “Of course!” soon. Other folks, c’mon join the discussion, share your mind.
If I keep this up, I should get an award for most-edited post…
I thought “grab this output pin & put it over here” was getting a little closer to an intuitive interface, but I wasn’t sure what to call it, and I’d already introduced the concept of “tearing” the node… The normal process would be to grab a pin and stretch the wire to the destination, this would be the same motion, but creates an output node with hidden link instead of stretching the wire.
Maybe a new symbol for the pins that generate a hidden link instead of a visible wire? The original bus node and the bus-out node could have a normal output pin, plus a “hidden link” pin (both would have the same value, but work different graphically). Since the link will be hidden, maybe the new pin suggests hidden by using a dotted-outline, or being grayed out?
Additional thoughts:
Should hidden-link pins be highlighted like normal pins when it has a connection (perhaps a checkered fill-pattern?)? I think so. Probably bus-out node hidden-link pins would never be highlighted, though; any links made from bus-out hidden-link pin really go back to original bus node hidden-link pin; otherwise highlighting to show hidden links shows a spaghetti graph instead of a clean star out of the original node. Bus-out hidden-link pins could be highlighted to indicate more than one bus-out is linked to the same original node, but I don’t know if that is a real benefit.
If dotted/checkered doesn’t work well with round pin, maybe hidden-link pins could be square, or just use triangle instead of worrying about dotted/checkered…
It should probably keep the color-coding for pin-type. This makes using grayed-out harder (but not impossible) to implement.
Do you show hidden links when any related node is selected, or only the original node? Probably any node so you can find original node from any of the bus-out nodes. Maybe the best idea is to show only one link when bus-out node is selected, but all links when original node is selected. (You could show links from bus-out node to all related nodes when bus-out is selected, but I don’t think that is a good idea; it would make original bus node harder to find.)
Ahaa. That makes much sense. Sounds intuitive enough. I didn’t understand you correctly in the first place because I don’t drag to create links. I click-click instead. And if the drag-n-drop behavior leaves no questions for buses, click-click is not so obvious. I will think about it.
One additional thought to the piggybank. A bus-in can act as some kind of multiplexing node with a single input and output. It may have an outstanding look (like buses or labels in electronics). When a xoder creates a link from bus-in output to an input pin, instead of drawing a link we draw some kind or counter-symbol from that input pin. Kinda small antenna.
click-click could create a bus-out node that follows mouse until click drops it at the current location…
Maybe I’m misunderstanding this, but it sounds like you plan to link the bus output directly to an input pin somewhere else with a hidden link. I was assuming we wanted a bus-out node created so that it could have a label linking back to bus-in node. This sounded more like the original request for flags. The bus-out output pin would then be linked to an input pin of the “destination” node. In my mind, the bus-out node does not do anything but provide the label & output pin to connect to next node, with a hidden link back to bus-in to provide the value for its output pin. The bus-out node is just window dressing to show where the hidden link is terminated with space for the label to indicate where it links to.
I envision the bus node being a horizontal pipe with label, and original bus node has vertical line up to input pin and multiple vertical lines down to output pins (one normal, one for hidden-links). The bus-out node can only be created by clicking on the hidden-link pin of a bus-in node (or just call it bus). The bus-out node would not have an input pin (maybe vertical line to missing input pin is still there for graphic affect of bus node) and its label would always be that of the bus node it was pulled from.
Yeah, it’s just one of the opportunities. The click on a destination input pin could create a bus-out node above it which may be manipulated later. Writing these words I see it’s a mess. Your proposal is better.
OK, we have plenty of variants to experiment with. We’ll try to create some mockups and see how it works. Alas, the schedule is quite dense and we can afford to work on the feature only after several weeks.
I appreciate your help. If you get new ideas, you’re always welcome
I guess you could allow both options if you think it would be useful. Double-click on hidden-link pin and it starts stretching a wire. Click on an input pin & it adds an antenna to indicate a remote input from bus; click on the workspace, and it creates a bus-out node with label. Same functionality for click-drag; what happens depends on where you release-click. Not sure having both is a good idea, but it would provide the most flexibility…
If you allow antenna for remote input directly to the pin, does hidden link get displayed when you select the node it is attached to, or only when you select the antenna? “Only when you select the antenna” certainly seems like a valid option; it is basically the same as selecting the wire between nodes and gives you a way to delete the hidden link. Clicking on the antenna should probably also display the label in the inspector window; maybe display all info from linked bus node…
