Fix diagnostic messages #937
Comments
|
A bug related to diagnostic is also: Just mentioning to create a xref. |
|
Regarding the errors:
but we are just passing the masks of the CAN boards that are
so we just need to add that piece of information to the par64, since |
|
Point 2 instead is quite weird, since it is related to this message: |
|
For point 1, we just need to parse at high level the par16, which contains the joint ID and it would be nice to make the mask in the par64 human-readable. For the generic error we are just passing to the pa64 the whole fault_state.bitmask, which is a uint32 made of this:
so we can create an ad-hoc function to check where we have the bits to 1 |
|
Regarding again the diagnostic error at point
Then another thing I'm wondering is if the temperature service related to the embObjFTsensor class is always initialized when using the FT sensors. Below an image showing the interesting line of code I'd like to check better:
|
UPDATEPoint 3:Need to remove the parsing at high level of the Point 2:Here, one of the problem is that the can mapping should be switched at a software level, since the parsing is done wrongly. Branches were we are keeping the development are: |
UPDATE 2Point 1Solved in the way that now the ID is shown. Working in improving wisely the management of a generic error so that it can be fully readable by the user Point 2Under investigation. Need to understand if services are initialized finely. Point 3Now should be fully solved in all its parts and fix are available here:
Problems related to that error can be summarized as follows:
NOTE:
So, in the moment in which we are going to be ready for the report the current time will be 50001 ms and therefore it would be different from the relative 250s in which will be set the boolean Here some text and images showing the difference before and after the modifications and the timing printed in the TRACE of the Debugger: BEFORE
AFTER
` |
|
@MSECode well done!!! 🚀 |
|
We still need to perform the tests on the setup with two boards connected to the same CAN port (i.e. strain +bat). |
UPDATE 3:Point 2regarding the error at point 2, i.e.: Trying to reproduce it with a setup basically equivalent to the ems eb1 of ergoCub SN00x, where we have the strain2c board and the BAT on the the CAN2, and the 2foc on CAN1, I realized that the aforementioned problem was related to the problem already found on the typo of the array used for converting the service category form the enum to the equivalent string.
So the service
Therefore I would say that this point is solved too. |
|
Add space for error missing boards during CAN discovery since CAN address is attached to the number of board 1 of X and it is difficult to read at first glance |
|
Just another minor improvement: from the image above, the period of transmission of the info Now we are sure, that when we lose a CAN board the error message is triggered suddenly, are we? |
|
Reset to 10 seconds. It looks reasonable to me. Regarding this point:
|
|
Opened all PRS:
|
|
Ciao @MSECode , For the final tests on the diagnostic, we can do the following actions on the setup you created (EMS+battery +Strain +2FOC).
Please you attach here the YRI log. thank you! What do you think? |
|
@valegagge
If we disconnect battery and 2foc the output is the following: After some seconds At reconnection i suppose 2foc cannot be recovered until restarting With 2foc and strain2c this one: At reconnection still errors |
|
Hi @MSECode , I just wrote done some notes for each point. 2: In the reported log I cannot see the 3: it is ok, the strain needs to receive the configuration and the start command because it is powered by CAN. 4:here I can see the 5: I noticed this discordance: Could you take a look at the diagnostic parser? If it is quickly we can fix it, otherwise we'll plan to fix it in the feature. From your experiments and taking a look into the code, the 2foc or, more in general, the motion control hasn't the canMotitor service. So, we cannot take the motion control service into account for this tests.
From the penultimate image I see that we have another parser problem: As before, If we have time, we can try to fix it otherwise we'll address it in the feature. In general, it seems that the inertial3 service diagnostic messages hide the canMonitor info of ft service. Is it possible to remove the inertial3 service from the config file? So our log, should be more clear. We can check it together. |
Point 2: We have the
|
Generic Error ImprovementI've hardcoded on the ems the rising of some of the bits of the bitmask for the motor fault
|
|
Also test removing and connecting again 2foc and bat or strain2c is fine. |
|
Here the logs of the test with the latest changes done today |
|
PRs merged. Dod satisfied. closing |
Bug description
In the log reported here, I noticed some weird diagnostic messages that might be worth investigating further.
426.026906 <ERROR> from BOARD 10.0.1.8 (left_leg-eb8-j0_3) time=467s 485m 342u : MC: generic motor error. (Error is a000000).==> Here the joint ID is missing418.960928 <WARNING> from BOARD 10.0.1.2 (left_arm-eb2-j0_1) time=460s 417m 341u : SYS: a service has detected that some CAN boards are not broacasting anymore. Type of service category is eomn_serv_category_temperatures. Lost can boards on (can1map, can2map) = ([ 13 ], [ ] ). ==> Why temperature? it was disabled. And what is the address13?420.013520 <ERROR> from BOARD 10.0.1.2 (left_arm-eb2-j0_1) time=461s 466m 194u : SYS: a service has detected that some CAN boards have stopped transmission. Type of service category is eomn_serv_category_all. Lost CAN boards are on (can1map, can2map) = ([ 2 ], [ ]). Time since last contact: 0 [ms]. ==> Why 0 ms?Steps to reproduce
See the ticket robotology/icub-tech-support#1726
Expected behavior
No response
Example repository
No response
Additional context
No response
The text was updated successfully, but these errors were encountered: