when sensor manager sends the request to physical process using gate index for sensor device :
send(requestMsg, "toNodeContainerModule", corrPhyProcess[sensorIndex]);
will the physical process receive the request message regardless of the distance with node? or whether the physical process receives the msg or not will depend on the distance?
The physical process has a fixed value and it never changes.
The physical process will always get the message from any node.
Figure 1 of the Castalia manual shows that a physical process module is connected to all the nodes. So when a node sends an OMNeT message to that module, it will be received.
Of course, what will the physical process do with the message and what value it will return, it depends on the specific physical process you implement.
Related
A network consist of 3 nodes, where 1 node is read-only and participates in every transaction. Request can start from either of the nodes which in turn creates a request state. It is received and processed by other node to create a new response state. Both only issue new states and do not consume the state. Both these state events are received by the read-only node. Would the State events received by the read-only corda node have an order or would it be processed in any order ?
For eg can we say that the request originator state event would be received/processed first and then the other node ? or can it be possible under high load that the other node request gets received/processed by the read-only node first and then the originators event is received.
My experience with corda is very minimal and need to understand
how events are received by the parties when one party acts as
read-only and all remaining parties only issue new states.
In general, the order of the receiving messages is not guaranteed. A node will process messages in the order it receives them. But it's not guaranteed that the received messages are sequential.
If Node A is receiving messages from Node B and Node C, and Node B produces a message before node C. There is no guarantee that the message from Node B is processed first. The one which reaches Node A first gets processed first. The delay could be because of multiple reasons like network latency, etc.
In my current setup, I have a LIN Master and a LIN slave. The schedule table is unconditional, and never re-negotiated:
Master Frame
Slave Frame
Slave Frame
I'm using physical bus and simulated Master (physical Slave). My goal is to apply censorship to certain LIN frames, in real-time.
For instance, I know that a request from Master (maybe single or multi-frame) will trigger a specific Slave response. I would like to catch this response, say in a CAPL script, perform checks on the content and apply selective censorship to it, so that the frame received by the Master doesn't say what the Slave transmitted in the first place. When no Master request is sent, both Master and Slave keep sending empty frames to fulfill the schedule table.
I can easily "catch" the frame with a non-transparent CAPL, but I'm unsure of how I would re-transmit it.
According to the output() keyword documentation:
To reconfigure response data of LIN frame. In that case RTR selector has to be set to 0. The LIN hardware responds to the next request of the specified frame with the newly configured data.
I don't want to add a delay of one message in transmission. And given the following constraints, I have no idea of how to do this, or if it is even possible with the CAPL API in CANoe:
I cannot foresee when a Master Request is broadcasted;
I know that Slave will reply immediately with acknowledge;
After a time that I cannot foresee, Slave will send additional data that I want to censor;
The Slave reply has to be modified in place and re-transmitted;
The original Slave reply must never reach the Master.
Rejected pseudo-code:
on linFrame 0x01 // <-- slave frame
{
if( payload I'm looking for )
{
// edit payload content
}
output(this)
}
Especially since
The original Slave reply must never reach the Master.
you have to physically disconnect Master and Slave and put CANoe inbetween
You would need a network interface with (at least) two LIN channels - one connected to the master and one connected to the slave - and need CANoe be setup as a gateway between these two channels. I.e. acting as a Master towards the Slave and acting as a Slave towards the Master.
In your gateway implementation you can then do whatever you want with the messages exchanged between master and slave.
Doable but not that much fun.
I have several ECAN within the PIC18 and PIC24 (on OpenCan) with Can Transceiver attached to the CAN Bus network. In event one module send a message and received by other modules (within ECAN), will all ECAN do CRC check and if passed, make dominate bit or just one one of many make this response?. In other words, does PIC ECAN make ACK response even the message is not assigned for that module?
CAN controllers generate dominant ACK bits if they receive the frame without any errors. ID filtering takes place after that. So yes, the CAN controller generates ACK even for the frames it's not interested in.
If a transmitter detects dominant ACK bit, it concludes that at least one node in the bus has received the frame correctly. However, it's not possible to determine if this receiver was the intended one.
As far as I understand, ACK bit makes it possible for a transmitter to self-check. A transmitter can think "If no one hears my message, then I should be the one having problems." if it samples recessive ACK bits. The reception of the message by the intended node should be checked by higher layer protocols, like CANopen.
Transmitter node transmits CAN MSG and monitors the bus for a dominant bit in the ack. slot. Receiver if receives the message correctly, will overwrite the ack. bit and make it dominant. If it does not receive the message correctly, it will not overwrite the ack. slot. Then the transmitter knows that one node has not received the message correctly because it will detect a dominant bit written by the other nodes and assume that all the nodes have received the correct message. Even if one node does not receive the data correctly the message is retransmitted by the transmitter.
Check if you can successfully transmit CAN messages. The problem you could have is in receiving messages. When you send a message to PIC, the message is not received. The message received flag is never set. You have to check that a message is being sent with the scope, check if your PIC stores it. Check which mode is it in, I assume 0, and if it is configured to receive all messages, even with errors.
Check on the scope if the PIC sends and receives the Ack response. When a message is then transmitted back to the pic, check if it sends an Ack response or receives the message!
CAN is a broadcast network so a node does not really know how many other nodes share the bus with it.
With that manner, all the nodes shall do the CRC check and ACK whether the messages are "assigned" (supposed to be received in application layer) by the listened node or not.
There are no conflict, since if there a error with CRC or ACK, all listened nodes shall send (active or passive) Error Frame which are same form from every nodes.
I recommend you to refer this excellent article:
http://www.copperhilltechnologies.com/can-bus-guide-error-flag/
When the physical process replies to node through sensor manager, I want to send source_snapshot[i].time along with retVal.
For this purpose, I am using phyMsg->setTimestamp() function in Physical Process and getTimestamp() wherever needed.
Is this the correct practice?
EDIT: or maybe I can add a time variable in physical process message structure?
I have a computer (that use as server) and several board with Atmega microcontroller Something like:
The computer connect to board on UART & RS485 (with a USB to RS485 converter)(I have limitation that lead to I could not use ModBus). I want to broadcast a message from server over bus and fetch the ID from of each board (Board ID is 4 digit).
When the boards receive broadcast message and try to send their own ID and the server receive some fake ID and I think it related to Collisions problem when all boards want to send data in one time.
After I search about this problem found a way that put a constant in each board that save a special delay for send data and when board receive broadcast message send ID with that delay...in this way it work fine and I dont see the Collisions but have some problem:
May be the delay number of 2 board be same.
Good way for small count of board.
Extra process when want to install board on bus.
Anybody know with this problem and could help me how to solve this problem with better solution?
You are mentioning Modbus in your question although some of your other stated facts seem to deviate from there (like 4-digit device numbers, and Modbus only has 1-255). Also, Modbus does not support responses to broadcast messages. I thus doubt a bit you are actually using Modbus.
A scheme you could use (and that is classically used in MA networks) would be:
Once a broadcast is received, have the clients scan the bus for responses for a time frame based on its station ID. If your client can see one, have it wait a minimum bus time (the time a module needs to answer your broadcast message based on current bus timing + the round trip for the master acknowledging the broadcast answer) plus an additional time based on its module ID, then go back to (1)
If a client sees the bus unoccupied for the specified time, send back a broadcast answer.
Have the master acknowledge the broadcast response from this client with the shortest possible message.
If a client that has sent a broadcast response does not receive a proper ack, go back to (1)
This is not 100% secure and absolutely not according to the Modbus specification, but could work.
* is a transmission, - is a "wait"
**** (Bus master broadcast)
--------- station 100 waits 100ms
------------------ station 200 waits 200ms
**** Station 100 sends broadcast response
------------------ station 200 sees bus active and waits another 200ms
*** master acknowledges broadcast response of 100
------------------ station 200 sees bus active again and waits 200ms from last seen activity
**** Station 200 has seen bus quiet for 200ms and sends broadcast response
*** master acks brc response of 200
This can take quite a bit of time and needs the waiting times finely adjusted against the transmission time of broadcast responses and response acks, but can work, and actually is implemented that way in a lot of CSMA/CD networks.
It will probably take longer, but here is another way to do it. First, design your protocol so that each command contains (or an can contain) an ID, and boards only respond to commands for their ID. Then, on your host, you would iterate through each of the possible IDs and send a simple command to each of them. If you get a response, you know there is a board with that ID. If you don't get a response after some period of time, you know there is no board there.