CAN connection lost as soon as sending any command to 3HC

Yao

I think a found a workaround by never homing the V axis from an already homed position.
So after homing this axis it must travel away from the switch before any other move.

I dont know how, or why the CAN error initiates, but it is solved by not having the limit switch for V axis on the 3HC board io_0 header active when initiating a new homeV.g or equivalent.

Not sure this issue is solved, but its a workaround.

dc42

@yao have you checked that the main board and all expansion boards are running the same major firmware version? The usual reason for getting CAN error messages (other than while updating firmware ) is that the main boards and expansion boards are running different major firmware versions. For example, 3.3 is not compatible with 3.4.0, however 3.4.1 is compatible with 3.4.0.

Yao

@dc42 Hello! , thank you for your suggestion. Yes I updated all boards to the latest 3.4.1 right after posting the question, Much easier than anticipated and fully automatic! I followed the progress by the messages and the lights blinking in succession on all the boards.

With the current workaround I still get the occasional CAN bus error, but it does not totally shut down the board. i can continue operating the machine.
It would be better to have no message at all...

dc42

@yao what CAN messages do you get now? It's not unusual to get occasional CAN messages during updating firmware or when you reset individual boards, however you should not get any during normal use such as when printing.

CAN error messages when running different major firmware versions on the main board and expansion boards are common, because the CAN protocols often change between versions in order to support new features.

Yao

@dc42 this is the only message i see in DWC:
Error: Response timeout: CAN addr 1, req type 6037, RID=130

On the screen i get multiple CAN warnings and a few about endstop not reached etc etc.

I found that if the endstop for V axis is already open (pressed by arm) before any other move for that axis i receive a CAN error and endstop fail.
Board hangs, but with the new firmware, if I manually push the arm away from the endstop I can resume function and movements, CAN is reestablished?

Yao

@dc42 quick question i ran into while testing this homing;

Is the DWC "run mesh compensation (G29)" button a different underlying command to the 'run mesh button' from the touchscreen? I am getting different behavior between the two.
As if the DWC one does not use the bed.g but only mesh.g ?

what are the differences between the two?

When I adjust the mesh parameters in DWC and then use the touchscreen button, it does use the altered parameter (not the ones from the config.g) is this correct?
If I would copy the bed.g file and rename it mesh.g the DWC "run mesh" button would behave the same like the bed.g called from the touchscreen?

<<SOLVED>> it appears the situation is as stated above.

Yao

@dc42 I changed the connection to the switch from "1.io0.in" to the main board "io1.in"
The result was such erratic behaviour from the switch and board, I suspected it was EMI interferance, placed a ferrite ring around the switch cable near the board.
All issues are gone.
This switch is the only one that runs along a motor drive cable. All the other ones are 1pair twisted and schielded...
and cable is 5 meter long.. so, yeah, my mistake.

<<SOLVED>> i hope.

dc42

@yao said in CAN connection lost as soon as sending any command to 3HC:

Is the DWC "run mesh compensation (G29)" button a different underlying command to the 'run mesh button' from the touchscreen? I am getting different behavior between the two.

There is no standard button on PanelDue that runs G29. If you have a button that runs G29 then I guess you have a macro file that runs it. Change that macro to run G29 instead of G29 S0, then it will run sys/mesh.g if it exists.

Yao

@dc42 there is a button on right, (little golfed line icon?) Under the macro section. When pressed it will run the bed probing?
What command is it calling then?

Phaedrux

That button runs bed.g which would make sense as that's a good place to put G29 as well.

Yao

@phaedrux Thanks! I was wondering what the difference between the two were. I now just made a copy of bed.g and renamed it mesh.g to get identical behavior between the two ways to run the bed probing.