0
\$\begingroup\$

enter image description here

above is the wiring of my CANbus. D1 is where the sensor values are coming from the robot. D4 is the radio receiver for the remote controller of the robot. The problem that I have is, the CANbus 1 is directly connected to the CANbus so that the CANbus is always fed with the information from the remote controller. So I do not have any chance to control the robot via CANbus, since my message gets overwritten all the time with the value from the remote controller.

So I thought I disconnect the terminals 4 and 5 and attach the CAN_H and CAN_L from my Laptop to there. Since a CAN connector needs to have a ground wire, I thought I just could combine the ground wire of the terminal 3 with the ground wire of my CAN connector. Is this concept reasonable?

UPDATE: So using the CAN bus wired like above I tried to read messages but it fails to read SDO Protocol as soon as I start ( SDO protocol timed out). Does anyone have a tip for me? enter image description here

UPDATE 2:

I spent another week with this project. To build my own gateway I bought 2 MCP2515 CANbus controller and 1 Arduino Mega 2600.

My concept can be seen in the attached image belowenter image description here. My plan is to read the CAN messages from the radio receiver (yellow box) and filter out the PDO messages. The filtered CAN messages are sent forward to CAN 1.

Problem : As soon as I disconnect the terminals 4 and 5, I cant read any CAN Messages with my microcontroller. I thought, if I can receive the CAN messages just as in my concept and modify it.

Does anyone have a clue, why the remote controller CAN-Messages cant be received like that? If the terminals 4 and 5 are connected, I can read out the messages without any problem. My assumption is that if I disconnect the terminals 4 and 5, the remote controller loses its functionality, since it is not connected to CANbus to send out the commandos. The remote controller does not work at all, if I disconnect the terminals, but I thought that the signals would be at the end of the disconnected terminals. It seems like that they just disappear ?

UPDATE 3: I found out that the termination resistor was built in my CANbus shield :No... the terminator resistor was already built in my CANbus shield..

https://www.amazon.de/AptoFun-Receiver-Protocol-Controller-Development/dp/B0758VD6WR/ref=sr_1_2?s=ce-de&ie=UTF8&qid=1539351966&sr=1-2&keywords=mcp2515

Now, I am more confused why it doesnt work... the only message that I receive with my arduino is : Standard ID: 0x701 DLC: 1 Data:
Besides, the interrupt pin of CAN is HIGH all the time, which indicates that something is wrong... but why ??

UPDATE...4: Since nothing seems to work, I came back to the root and tried to find out why the CAN messages are not arriving at the arduino. I disconnected my arduino and attached my PEAK-CAN adapter to 2 points. I wanted to analyze what the hell is going on..

  1. Point : After disconnecting the terminals 4 and 5, I attached the adapter to there as below. enter image description here

Result : https://drive.google.com/open?id=1Jc-0ebUqvnVgbMzBlHAT8A3vPJnUeQsd I tried to read out the PDO values and I assume that the initializing the SDOs worked, PDO values were successfully expedited. The problem is only the init. PDO values were able to read. Manupulating the joystick didnt provide me new messages. So the problem that the CAN messages are not arriving still remains.

  1. Point : This was actually my very first attempt. So I didnt disconnect anything, but just attached my PEAK-CAN Adapter to the terminals 7 and 8. enter image description here

Result : As expected, the CAN-Messages could be succesfully read out. The problem is that the PDO values are read out every 50ms, which means that PDOs are overwritten with the remote controllers default value '' 0A 00 0A 00 00 00 00 FF'' (in case 0x181h) every 50ms. As you can see in the small window above right, I tried to send my PDO messages, but no chance. It gets directly overwritten. The problem that the CAN messages are not arriving is not there anymore, however the origin problem is there.

enter image description here

What can I do in such a situation? Didnt expect that this damn CANbus costs that much work....

\$\endgroup\$
11
  • \$\begingroup\$ SDO protocol... Are you sure the network is running CANopen? Are you able to observe messages on the network? \$\endgroup\$
    – user28910
    Oct 11, 2018 at 17:49
  • \$\begingroup\$ Yes, added a screenshot. \$\endgroup\$
    – Joe
    Oct 11, 2018 at 18:00
  • \$\begingroup\$ Looks like your'e communicating, so your connections to the network are fine. What are you trying to accomplish? \$\endgroup\$
    – user28910
    Oct 11, 2018 at 19:07
  • \$\begingroup\$ I want to send a PDO from my laptop so that I can control the robot with it. However as you can see, I get this SDO runtime error as I start the motor. \$\endgroup\$
    – Joe
    Oct 11, 2018 at 19:17
  • \$\begingroup\$ Hmm... Are all the messages in the screenshot coming from you? Maybe you're not communicating. Are you using node ID 30? \$\endgroup\$
    – user28910
    Oct 11, 2018 at 21:10

2 Answers 2

Reset to default
1
\$\begingroup\$

Problem 1 seems to be that the device you are connecting to does not share a signal ground internally. Meaning that the reference for the CAN signals will either be the dirty supply ground, or none at all.

Problem 2 seems to be that the device is only terminated in one end instead of both ends.

You need to clear out these issues with the device before connecting anything to it. Start by measuring the resistance between CAN Hi and CAN Low, is it ~60 ohm? If it is, locate the resistors. If not, add resistors. (120ohm, roughly 0.4W)

With the problems on the device solved, you can connect your own hardware to it.

If there are terminating resistors on the side that you disconnect, you will need to add some on your side instead.

Further things to check is that your own CAN device is in normal operational mode and not some loopback or listener mode where it doesn't ack the received messages. This is common with demo boards and CAN listener devices.

Galvanic isolation is always nice but shouldn't be necessary. Particularly not if you have proper signal grounds.

\$\endgroup\$
9
  • \$\begingroup\$ Problem 1 : So I always connected the GND-wire of CANbus to the ground port of the device. Problem 2 : Pls have a look at the 4. Update. The resistor was 120 Ohm. CAN device is in normal operational mode. \$\endgroup\$
    – Joe
    Oct 18, 2018 at 8:23
  • \$\begingroup\$ @Joe So it is not a hardware problem at all? From the log you posted, it is clear that "device x" sets up "device y" in run-time, with SDOs. In particular the PDO communication parameters, COBID and mapping. If you were to plug out the device sending these SDOs, the whole PDO communication would be wildly different. But it's not clear to me which device that does what here. \$\endgroup\$
    – Lundin
    Oct 18, 2018 at 8:49
  • \$\begingroup\$ I am not sure which log you are referring to, but in generall the remote controller boots up the robot. So "device x" must be the remote controller, in log file ID 30. The "device y" must be the robot, ID 1. It must be a hardware problem, since I am not using a self-coded programm for logging/ analyzing. But the problem doesnt seem to lie on that points you mentioned. \$\endgroup\$
    – Joe
    Oct 18, 2018 at 9:01
  • \$\begingroup\$ Besides, can you say more in detail about " the whole PDO communication would be wildly different " after pluggin out the device. A reference or something that I could read in ? \$\endgroup\$
    – Joe
    Oct 18, 2018 at 10:31
  • \$\begingroup\$ @Joe PDO communication parameters determine how often a PDO is sent, if at all. COBID is the CAN identifier. PDO mapping is the contents. can-cia.org/can-knowledge/canopen/pdo-protocol \$\endgroup\$
    – Lundin
    Oct 18, 2018 at 10:51
-2
\$\begingroup\$

No, because the industrial controller is most probably using galvanically isolated CAN transceiver. This is normal praxis in industrial controls. So you need a galvanically isolated CAN Adapter to connect the device. You connect only CAN_H and CAN_L.

\$\endgroup\$
12
  • 2
    \$\begingroup\$ This answer is wrong. Isolated and non-isolated devices can be mixed freely on CAN. And you always need to connect GND for CAN. \$\endgroup\$
    – Timmy Brolin
    Oct 11, 2018 at 22:00
  • 1
    \$\begingroup\$ @TimmyBrolin As a filed engineer, I connected many CAN industrial devices during my career and they have only two terminals, no GND. Except for the shield which is directy tied on the metal case - ground/earth. \$\endgroup\$
    – Marko Buršič
    Oct 12, 2018 at 6:10
  • 1
    \$\begingroup\$ Then those devices used the shield as GND reference. Not uncommon in automotive where you have a common chassi ground. CAN does not work reliably without a common GND reference. \$\endgroup\$
    – Timmy Brolin
    Oct 12, 2018 at 12:54
  • 1
    \$\begingroup\$ I can confirm that there are a whole lot of sloppily designed CAN devices on the market. Many of them are malfunctioning. Using the shield as signal ground simply isn't professional, it defeats the purpose of using a shield in the first place - namely to lead unwanted EMI away from the signals. And obviously you shouldn't connect the shield in both ends. A lot of sloppy CAN electronics in the industry relies on the supply ground potential between the nodes being within the tolerance of the rugged CAN transceiver and that the differential line decoding takes care of the rest. Aka quackery. \$\endgroup\$
    – Lundin
    Oct 17, 2018 at 13:50
  • 1
    \$\begingroup\$ It's should be bloody obvious that you if you connect a PC with supply from 230VAC mains to some industrial robot with supply from a 24VDC battery/generator, you need to share a common signal ground or nothing will work. This is very fundamental electronics that shouldn't need to be explained. Nothing unique to CAN. \$\endgroup\$
    – Lundin
    Oct 17, 2018 at 14:01

Not the answer you're looking for? Browse other questions tagged or ask your own question.