Welcome to our new forum
All users of the legacy CODESYS Forums, please create a new account at account.codesys.com. But make sure to use the same E-Mail address as in the old Forum. Then your posts will be matched.
Close
New Codesys user seeing if anyone has a good design or pattern for handling application specific errors to be sent over canbus/j1939 for notification to the user. Application errors such as e-stop engaged, voltage not in bounds, or circuit disconnected etc to help inform the user what is wrong.
Possible Requirements:
1. Persistent till error condition clears up in the event a high priority message on the bus comes in
2. Only have to be one error code at a time, variable error list would be nice :)
Few things I have thought:
1. Have a global error code variable that any FB can set. Issue is spreading error code in every other FB to handle that making the code a mess.
2. Think I saw a mention of having an Error FB to add or remove errors as they come up. I guess a FB would have a input for every FB it would support? Not for sure how to cleanly implement this as each FB would need to continously update the error FB when an error condition occurs or is cleared. OR have some kind of timer for each error code so if the source FB doesn't post an error, it will timeout and clear itself. This already sounds complicated!
These options so far don't feel like they pass the sniff test so far or I may be crazy. Anyone has a better design to share?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'd not use a global error variable. Each fault should have its fault bit with its own resetting/acknowledging logic.
Since you mention J1939, have you thought of implementing a DM1/DM2-like system?
With a program (not a FB) executed after the logic, you "project" the fault bits (that could be global or local) into a DM1 list and then send it as per J1939 customary.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Maybe it is even better to think of a fieldbus independent error diagnosis?
In theory the fieldbus type itself is not important or relevant for proper error-diagnosis handling.
Each error should have its own reset functionality but can be resetted by a single global reset action, likewise to what @sgronchi proposes. When the design pattern is wel thought through I bet it will not matter which fieldbus is used underneath.
Never ever let an error auto reset itself unless the user has configured an alarm in such a way! So every alarm can be configured to be auto resetable but it should not be auto resetable by default.
Tip: use interfaces to implement the alarms so that you can be flexible without having to reprogram your application code when adding/removing alarms.
Last edit: aliazzz 2020-05-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yes, in fact I talk about a projection of the various faults to the fieldbus.
If you have e.g. a CANopen network you can also project the fault bits onto 1003h array in object dictionary and send one or more EMCY message(s) in an independent program (better than mapping faults onto two, three or more fieldbuses in the same program).
I talked about DM1 because the OP talked about reporting errors via J1939, but the approach is fieldbus independent.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So funny enough we had another ECU device that started having issue. The vendor broke down the DM messages for us and sounds like I'll be deep diving on the DMs one way or another as I missed this during implementation.
From the responses it sounds like either 1003h array or DMs are the way to go. I appreciate the responses!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
New Codesys user seeing if anyone has a good design or pattern for handling application specific errors to be sent over canbus/j1939 for notification to the user. Application errors such as e-stop engaged, voltage not in bounds, or circuit disconnected etc to help inform the user what is wrong.
Possible Requirements:
1. Persistent till error condition clears up in the event a high priority message on the bus comes in
2. Only have to be one error code at a time, variable error list would be nice :)
Few things I have thought:
1. Have a global error code variable that any FB can set. Issue is spreading error code in every other FB to handle that making the code a mess.
2. Think I saw a mention of having an Error FB to add or remove errors as they come up. I guess a FB would have a input for every FB it would support? Not for sure how to cleanly implement this as each FB would need to continously update the error FB when an error condition occurs or is cleared. OR have some kind of timer for each error code so if the source FB doesn't post an error, it will timeout and clear itself. This already sounds complicated!
These options so far don't feel like they pass the sniff test so far or I may be crazy. Anyone has a better design to share?
I'd not use a global error variable. Each fault should have its fault bit with its own resetting/acknowledging logic.
Since you mention J1939, have you thought of implementing a DM1/DM2-like system?
With a program (not a FB) executed after the logic, you "project" the fault bits (that could be global or local) into a DM1 list and then send it as per J1939 customary.
Maybe it is even better to think of a fieldbus independent error diagnosis?
In theory the fieldbus type itself is not important or relevant for proper error-diagnosis handling.
Each error should have its own reset functionality but can be resetted by a single global reset action, likewise to what @sgronchi proposes. When the design pattern is wel thought through I bet it will not matter which fieldbus is used underneath.
Never ever let an error auto reset itself unless the user has configured an alarm in such a way! So every alarm can be configured to be auto resetable but it should not be auto resetable by default.
Tip: use interfaces to implement the alarms so that you can be flexible without having to reprogram your application code when adding/removing alarms.
Last edit: aliazzz 2020-05-16
Yes, in fact I talk about a projection of the various faults to the fieldbus.
If you have e.g. a CANopen network you can also project the fault bits onto 1003h array in object dictionary and send one or more EMCY message(s) in an independent program (better than mapping faults onto two, three or more fieldbuses in the same program).
I talked about DM1 because the OP talked about reporting errors via J1939, but the approach is fieldbus independent.
So funny enough we had another ECU device that started having issue. The vendor broke down the DM messages for us and sounds like I'll be deep diving on the DMs one way or another as I missed this during implementation.
From the responses it sounds like either 1003h array or DMs are the way to go. I appreciate the responses!