Feature Request: Visual diagram rearrangement

[OriolFM]

First of all, thanks for creating this extremely useful node. I am using it now to implement some FSM for industrial control and works very well.

I am currently not using the data feature to pass on to certain states because I had some issues with object nesting when I tried to pass on data from one iteration to the other, so I tend to save the data I want to keep in global variables while evaluating the transition conditions to the next state.

What I noticed is that when FSMs get more complex, the diagrams are almost impossible to visualize. I think the self-arrangement feature is cool, but it's quite limited by trying to keep the arrow lengths as short as possible, having lots of overlapping.

Since the diagrams are very useful to me when I'm working on the program, I currently have to copy the SVG object from the browser inspection tab, import it into inkscape, edit all the fill/stroke settings for the arrows and circles, and manually reposition the circles and arrows one by one. The fact that they are SVGs helps with the size problems because I can resize them in inkscape, but once I copy the text from the browser, the arrows and circles are not linked anymore.

If it's possible to allow for some resizing of the arrows (maybe by pressing a key while draggingthe circles) that would already help a lot, making them easier to see. Resizing the diagram window if there's space for it would also be great.

Thanks again. I'm sorry I don't know enough programming to be of use in this regard, but I can give any feedback or help in any other way, let me know.

[lutzer]

Hey, yes the visualisation is not very useful for big fsms. could you maybe send me your transition table so i can try it out? I didnt really understand your suggestion. you want to be able to extend the size of of the arrows and also remember it when you open the node the next time?

Could you also send/tell me an example where the problem with the nested data object occurs?

[OriolFM]

Ok, attached is the transition table I'm currently working with, one of the two I posted in my previous example. It is part of the logic for a mobile robot to handle loading/unloading jobs.

You'll see it's even more garbled than before, because I had to handle the transition from any state into offline (should the connection to the fleet server fail, I have to record that the robot is offline, so the job handler can reassign the job to some other robot).

About the nested data object, I currently don't have any example. What I found is that if I pass data on to the FSM externally with the transition messages, but I also set data when the FSM enters a state via the table, there's some nesting occurring after a few cycles.

To prevent that, I had to clean all the data before feeding it back into the FSM.

In my current model, I have the FSM send a message with all the status transitions. In my transition subflow, first of all I query the fleet manager for the current operational status of each robot, plus several statistics like battery voltage, current consumption, internal temperature, position, bearing, the last command status, and so on. I save this into global variables.

Then I have a bunch of switch nodes that separate the branches for each status and trigger them.

All the statuses have a reload loop triggered by a timeout that is adjusted independently for each status. For instance, I don't need to check the status too often if the robot is charging, but on the other side, when it is docking into a machine, I should query it much faster, to see if the docking is already finished.

For instance, this is the CHARGE branch. This is entered once the server reports that the robot has started charging, and just checks for the charging finished status from the server (which is picked on by the info update before executing the branch).

The last three change nodes set the topic for the transition, and clean all the payload to avoid nesting. If I don't clear the payload and I add data in the transition table and the messages I pass onto the FSM, I'll get object nesting in the payload, and after a few iterations, the payload has become huge. This way, I can keep things smaller and make sure all the information I get is fresh.

AGV_FSM.txt

[OriolFM]

Could you also send/tell me an example where the problem with the nested data object occurs?

I opened a new issue for the nesting trigger object, I figured it out and posted a workaround.

[lutzer]

Hey Thank you for pointing it out again. the problems with the nested data object i understood now and it should be fixed in v2.1.1. The visualisation i didn't tackle yet. it requires definitely more work to fix that.