Some (small) improvements to VAL3

[JohannesFriedrich]

Good evening all together,

my name is Johannes and I´m an software engineer at Staubli (Germany).
I have not much experience with ROS yet but I´m very familiar with VAL3. I had a look at the code and found some small improvements to make the VAL3 code more stable:

• check all return values of libInterface:libLoad in start(). In case of error: popUpMsg("...")
• instead of taskKill("ros_server~") I would call stop() and then
• Kill all tasks in stop()
• Check for overruns in the synchronous tasks
• Check if tasks are really started in start()

These changes could be done very fast and without much effort.
Even more effort need some other things I would recommend:

• Create a task manager to check the state of the tasks and eventually start them again. Until now, if someone kills a tasks on the SP2 it is gone and not automatically restarted. This is not ideal for production.
• Init all variables (especially) bools to a specific state. When someone saves the application on the SP2 and starts it again there is no guarantee that the variables have default values any more.

You are much more experienced then me and I´m open to discussions about my points above. If you agree to some of them, I would make the changes in my branch and then PR it here.

I would also like to improve the driver from VAL3 side if there are any topics I can help you!
Thanks for your great work,

Johannes

[gavanderhoorn]

Hi, thanks for reaching out.

Yes, we would be very much interested in the improvements you suggest.

Everything which will improve the user experience is always welcome.

There is some discussion around other possible improvements in #32, where @enginkarlidag explains what kind of changes they've made in their fork.

@marshallpowell97 is from Staubli USA, we should try to coordinate with him as well.

If you agree to some of them, I would make the changes in my branch and then PR it here.

please open PRs. They will allow us to focus the discussion and review the changes. There is always a chance things won't get merged as-is, but that wouldn't be a problem. That's exactly what PRs are for.

You are much more experienced then me and I´m open to discussions about my points above.

Personally I could not claim to be more experienced, at least not on the VAL 3 / Staubli side.

So we're happy to have you here 👍

[gavanderhoorn]

@JohannesFriedrich: friendly ping?

[gavanderhoorn]

@JohannesFriedrich?

[JohannesFriedrich]

Thanks for the reminder. I found some time today to program the changes, see #39
I´ve tested it on CS8C and CS9 in SRS on the emulator and works well.
Feedback very welcome!

[simonschmeisser]

Could you please explain what a overrun is and what should be done if it happens?

Great to see your improvements!

[JohannesFriedrich]

@simonschmeisser

From the VAL3 manual:

If the execution of a VAL 3 synchronous task takes longer than the specified period, the current cycle ends normally, but the next cycle is canceled. This overrun error is signaled to the VAL 3 application by setting the Boolean variable specified for this purpose at the task creation to "true". At the beginning of each cycle this Boolean variable thus shows whether the previous sequencing was carried out entirely or not.

If you have a synchronous task which receives/sends data in the given cycle time and is not able to do so, it´s critical to know if the task could receive/send the data, e.g. if you want to control an external axis.