I have a doubt. I am working on CAN protocol which uses CSMA-CD and Arbitration mechanism to transfer message. I am planning to implement single Server Node and Multiple Client Nodes.
Server is given ID of 0 (11-bit Identifier).
When node is powered on it should get a ID to communicate in the network so it requests one from Server. Node uses Remote Frame to request ID from server which involves ID = 0 (Server ID), DLC = 2
My doubt is, there are multiple nodes on the CAN Bus so each node requests an ID from Server. And all the nodes use ID = 0 (Server ID), DLC = 2 as Remote Frame. Now suppose 2 or more nodes at the same time sends message to server arbitration mechanism is not going to work because both the nodes get control over the CAN BUS. So did CSMA-CD will prevent this and allows only a single node to communicate at a given time?
If a device does not have an ID, CSMA-CD will not help because every node needs an ID in order to participate in the CSMA-CD flavor of the CAN bus protocol. Then, if it cannot access the bus, it cannot request an ID. As you see it is a chicken-egg kind of problem.
You could assign an unique ID to every node on the bus, then every node could request a new ID, but I guess that is like double-work...
Maybe it will be useful to learn about the arbitration mechanism in CAN protocol. In short: lower ID implies higher priority.
Related
I am new to CAN communication and one of my tasks is to use a CANalyzer to learn what message IDs are being used for a product and what data is being sent/received.
The product has multiple nodes that can send/receive CAN messages. I know CAN messages are broadcasted to all the nodes, but the part I'm having a hard time determining is which node transmitted the message and which nodes received it.
So, for example, if I have 3 CAN nodes, is there a way I can determine that Node 1 sent the message and Node 2/3 are receiving the message?
Thank you in advance.
Generally, you can't know this by listening to the CAN bus alone. The same old story whenever someone asks about data on "CAN bus" is: what application layer protocol is it using? "CAN bus" doesn't tell you jack, it's just the specification physical and data link layers. The concept of identifying individual nodes does not exist on the data link layer, only on the application layer.
There's two possible ways for you to tell:
If you know the application layer used on top of the physical CAN bus and know that it uses node id, then you can tell which node that is sending what data by decoding the application-layer protocol.
On each node, you can sniff the Tx signal between the MCU and CAN transceiver with an oscilloscope. That one only goes active when a node is sending or ACK:ing. Most modern scopes has a CAN frame decoder feature, saving you the head ache of decoding the frames manually.
I am new to Canopen and need to architect a system with the following characteristics:
1 canopen Master (also a gateway)
multiple canopen slave nodes, composed by multiple instances of the same device (with unique SNs, as required by LSS)
I would like to design this device to not require any pre-configuration before connecting it to the bus, and also allow devices that were previously connected to another canopen bus (and therefore had a previous node ID) to be seamlessly connected to a new bus (therefore their node IDs should not persist after a reboot).
After learning about Canopen and the LSS service I think a good solution would be:
The device has no persistent node ID, and at every boot it needs to be addressed by the master through LSS
the master will periodically scan and address new nodes through the LSS service (allowing device hot-plug)
If for any reason the master reboots, it can re-detect all already addressed nodes through a simple node scan (SDO info upload of all addresses)
Now my questions:
It is not clear to me how to have an "invalid canopen node-ID" (referenced here: https://www.can-cia.org/can-knowledge/canopen/cia305/) when they boot, if it has no initial node ID (and therefore only replies to the LSS addressing service) it should be completely silent on the bus, not even sending a boot-up message when powered (not being canopen compliant) until it gets addressed by the LSS service, but if I give it any default initial node-ID it would cause collisions when multiple nodes are simultaneously powered on (which will be the normal behaviour at every system boot-up, all devices, including the master, will be powered on at the same time), is it valid to have a canopen device "unaddressed" and silent like this, and still be canopen compliant? how to handle this case?
I read that node ID 0 means broadcast, so it means that my master could ask for all (addressed) node infos (through an SDO upload) with just one command (SDO upload info on node ID 0)? or is it not allowed, and I should inquire all 127 addresses on the bus to remap the network?
Thanks
I hope I get your questions because they are bit long:
Question 1
Yes, it is CANopen compliant if you have a Node which has no Node-ID. That's what the LS-Service is for. As long as the LSS Master has not assigned a Node-ID to the slave, your are not able to talk to the slave via SDO requests. Also PDO communication is not possible in unconfigured state.
Question 2
The ID 0 broadcast is only available for the Master NMT command. That means the CANopen master can set all NMT states of the system at the same time. SDO communication is only available between the Master and one Slave so you have to ask every node individually.
Suppose we have 3 lightning nodes and a underlying bitcoin network, we need a way to create a 3 of 3 multisig address, where one node will send some satoshis to the multisig and the 2nd node will be able to withdraw the satoshis after some time lock is over with approval of 3 nodes
This won't be possible without patching a lightning node implementation and breaking the protocol. Currently payment channels are 2-2 multisig wallets. Also with the payment channel construction that we currently use such an escrow service will create a huge implementation overhead. With eltoo channels multiparty channels might become a thing but eltoo requires a Bitcoin softfork
I have a virtual socketCAN network. How do I block a particular ID from being sent on the network?
If a node is connected to a CAN bus, at the lowest level it cannot be prevented from sending any message externally.
However, there are 3 things that can be done:
Add a gateway - a device that separates the bus into multiple small buses and passes messages from each sub-buses to the others, it does not prevent any node from sending a message, but it will not pass it to the others. This solution have a few clear drawbacks - it requires a separate device with multiple CAN interfaces (up to the number of nodes on the bus), it adds a delay for each message, and it renders the ACK bit unusable.
Apply filters for the received messages in each node. Again, this will not prevent sending the message, but will drop the load on the nodes. Most CAN controllers have hardware support for filtering by ID or a bit mask of ID.
There are some CAN controllers that can block the sending of messages, again, this will require adding such controller and setting it up for each node in the CAN bus.
Let assume I have two ejabberd server consider X and Y which has the same source and i did ejabberd clustering for those server by using this. Now consider A and B are user and those are connected in X server. Both A and B are in ONLINE state and those are connected via X server. If suppose X server is get shutdown or crashed by some issue. In this sceneraio whether the A and B are get OFFLINE state or A and B are in ONLINE state which is handle by Y server. I don't know whether my thought is right or not. If any one give me the suggestion about it.
If you have nodes in different physical locations, you should set them up as separate clusters (even if it's a cluster of 1 node) and federate them. Clustering should only be done at datacenter level since there are mnesia transactional locks between all nodes in a cluster (e.g. creating a MUC room).
"Load balancing" is not what you are describing in your question.
In load balancing, a incoming connections are distributed in a balanced fashion over multiple nodes. This is so that no one server has too high a load (hence the name "load balancing"). It also provides fail-over capability if your load balancer is smart enough to detect and remove dead nodes.
A smart load balancer can make it so that new connections always succeed as long as there is at least one working node in your cluster. However, in your question, you talk about clients "maintaining the connection". That's something quite different.
To do that, you'd either need the connection to be stateless or you'd need each client to connect to all nodes. That's not how XMPP works: it's a stateful connection to a single server. You must rely on your clients to reconnect if they get disconnected.