Skip to main content
shopping_basket Basket 0
Login
PYTHON – Let the „Monty-language” enter Automation: Part 4
VdH
4
Volker de Haas started electronics and computing with a KIM1 and machine language in the 70s. Then FORTRAN, PASCAL, BASIC, C, MUMPS. Developed complex digital circuits and precise analogue electronics for neuroscience labs (and his MD grade). Later database engineering, C++, C#, hard- and software developer for industry (transport, automotive, automation). Ended up designing and constructing the open source PLC / IPC "Revolution Pi". Today engaged in advanced development as a service.

Comments

November 21, 2019 08:27

Why have most of the comments dissapeared on this article series? There was useful information in several comments that I came back to refer to and it's disappeared.

0 Votes

November 21, 2019 09:58

@PeterTecks DesignSpark moderator here. We've been back through all comments and can only find one deleted comment - which was a test comment as Sven Sager was unable to post his comment due to some code he was trying to provide. I've moderated and approved his comment now to signpost to the end of the article, as we added his comment there. Are you sure the comments you're referring to were not on another @VdH article, such as his popular 'Classical Automation' series? https://www.rs-online.com/designspark/classical-automation-enters-alien-world-of-it-the-core-differences-explained-in-a-nutshell

VdH

August 7, 2019 07:04

Many thanks to Sven for his comment!
If you want to think a little further about robust industrial automation applications, you should also consider the following enhancements:
Find out what would happen to your actuators when the application runs into an error. Do they need to be switched into a safe state? What would that safe state be? There are several methods you could use to establish this safety measure. The RevPi digital and analogue outputs (in our example the DIO output for the light bulbs) do switch into 0 V mode whenever the PiBridge driver between RevPi Core and RevPi IO modules crashes. But if only your application crashes this would not help. The outputs would simply stick to their last state. So you would need to monitor your application. This can be done by a "software watchdog" which is a separate piece of software running independently from the application and waiting for a cyclical message from the application. But what if all userspace programs are blocked (including the watchdog)? Then you would need to use a hardware watchdog. This is a separate piece of hardware which needs to be cyclically reset to prevent a timer to elapse. If the timer elapses, the system will be reset by the hardware watchdog. There is an integrated hardware watchdog in the RevPi Core Compute Module. Read this thread to learn how to use it and what pitfalls are involved: https://lb.raspberrypi.org/forums/viewtopic.php?t=216240 . If you are using the "RevPi Connect" CPU, you can also use the external hardware watchdog of this Controller. See this article to get more information: https://revolution.kunbus.de/forum/viewtopic.php?t=862

0 Votes

November 21, 2019 09:46

  • Moderated

N.B. DesignSpark has added my comment to the end of the article (see above). The code I provided was prohibited in the comments section.

0 Votes

Related Content

DesignSpark Electrical Logolinkedin