I am writing a CAPL script to mimic a CAN message on network. While I am getting intended message, direction is both Tx & TxRq. How I can filter out and send only Tx message.
I tried CANID.dir=1 (tx) however not getting intended result.
Message details
I tried, setting direction as CANID.dir=1 (tx).
According to your screenshot, I assume took from the Trace window, you are looking at duplicate entries that spark confusion.
The entries marked as Tx are telling you that there is, indeed, a CAN frame with direction "outgoing" from your measurement system (your Vector Node).
The entries marked as TxRq are send requests. You may change settings for send requests in the Vector Hardware Configuration tool (ref).
TxRq is not a "direction" per se, just a way to indicate a different type of log in the Trace window. Remember that the only directions available are Tx and Rx (all frames either go out of your node or come into your node).
More about send requests. The following is an extract, I don't remember from which Vector knowledge base entry
By default, this box [the one in the Vector Hardware Configuration] is unchecked because most users do not require
this feature. This feature displays the TxRq messages with a time
stamp in the Trace window of CANoe. These are requests to send
messages by CANoe that have not yet been transmitted onto the CAN bus.
If they have been transmitted on the CAN bus, they would be Tx
messages.
Vector Network Hardware Configuration
If you get similar issue, pls go to simulation setup, channel on which you have simulated node, go to Network hardware & untick Activate TxRq
Related
I'm using the wireless example, and i want get the simulation time and save in parameter for calculate the time the packet arrival and the packet send. Have anyone solution for these?
There is a statistics for this automatically collected in application models (i.e. like BasicUdpApp etc.). It's called endToEndDelay.
The proper way to do this (and this what is already done in INET) is that you during packet creation you should add a TAG to the sent packet which contains a simtime_t variable and put the actual simtime there and then read the same TAG when the packet arrives and calculate the difference. Putting values into the "parameters" of a message would NOT work as the packets could be fragmented/defragmented in the network so their identity is not kept and the attached parameters are destroyed.
But again, this is already present in INET 4.2
In a LIN simulated slave node, what is the difference between output and linUpdateResponse?
From output docs:
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.
So, I can reconfigure the output and next time (real?) hardware should talk I've successfully override it, right?
From linUpdateResponse docs:
Updates the response data of a specific LIN frame.
letting me set data length (dlc) and data content for a specific frame ID.
How are they different and are there examples available? I can't quite understand how to use the latter with the example provided.
For LIN slave nodes, there is not really a difference between output and linUpdateResponse.
Both modify the internal state of the (simulated) slave and change the frame that will be sent the next time the master asks for the frame.
As you have posted, when using output you have the set the RTR selector.
But apart from that, there is no difference.
I, personally, think that linUpdateResponse is more convenient to use.
As part of CanTp protocol related tests, I have been trying to test N_As and N_Ar timeout errors, where N_AsMax = 1000ms and N_ArMax = 1000ms.
Is it possible to create the N_As and N_Ar timeouts with CANalyzer and/or using CAPL?
It would be great help, if you can share a possible way to test these timing parameters using CANalyzer or CANoe.
CanTP is a protocol to extendend the maximum data length (in bytes) of any given CAN data frame over the traditional 8 bytes, please refer to ISO 15765-2. Here you can have Single Frames, or Multi-Frames, which are trains of related frames each one carrying a portion of the overall PDU. A flow control frame is sent, usually by the receiver, to address and instruct the transmitter on the protocol to be used for frame splitting.
According to docs,
N_Ar [is the] Time for transmission of the CAN frame (any N-PDU) on
the receiver side (see ISO 15765-2)
N_As [is the] Time for transmission of the CAN frame (any N-PDU) on
the sender side (see ISO 15765-2).
In addition, the following requirements are relevant:
[SWS_CanTp_00075] ⌈If the transmit confirmation is not received after
a maximum time (equal to N_As), the CanTp module shall act as if it
had received an unsuccessful transmission confirmation and any late
confirmation shall be ignored. The CanTp module shall cancel
(internally) the failed transmission. ⌋ ( )
[SWS_CanTp_00311] ⌈In case of N_Ar timeout occurrence (no confirmation
from CAN driver for any of the FC frame sent) the CanTp module shall
abort reception and notify the upper layer of this failure by calling
the indication function PduR_CanTpRxIndication() with the result
E_NOT_OK. ⌋ ( )
Coming back to your question:
Is it possible to create the N_As and N_Ar timeouts with CANalyzer and/or using CAPL?
Yes, by means of the osek_tp.dll file that you should have in your local CANoe install (I'm using CANoe v10.0). Examples on how to use it are well documented in the help document AN-IND-1-012_CAPL_Callback_Interface.pdf, again it should be distributed in your CANoe install folder.
According to that document,
Basically, the OSEK_TP.DLL implements fault injection functionality
that has to be enabled explicitly in order to prevent unintentional
usage. Once activated, it is possible to setup a specific fault on a
connection that is executed during the next data transfer.
I'd urge to give it a read, and refer to linked documentation as well. I hope this is pointing you in the rigth direction.
Additional info:
Transmitting data over ISO-TP in CANoe using CAPL
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/
I'm working with the Veins framework over the OMNeT++ simulator and I'm facing a weird situation where certain few nodes lose all received packets.
To put everybody in context, I'm simulating 100 nodes (4 flows of 25 nodes), all under coverage (apparently), and sending 10 packets per second each. Depending on the moment the nodes enter the network (i.e: are created by SUMO), some of them (usually just 1 but can be 2, 3, 4...) enter in a mode where all packets are marked as lost (SNIRLostPackets) as they receive a packet while another packet is already being received (according to the Decider the NIC is already synced to another frame).
That doesn't suppose to happen in 802.11 unless there are hidden nodes and the senders don't see each other at the moment of sending their respective frames (both see the the channel idle) right?
So, this behavior is not expected at all and destroys the final lost packets statistics. I tuned the transmission powers of transmission and interference range but nothing changes.
It happens too often to ignore it and I would like to know if anybody has experienced this behavior and how it was solved.
Thank you
(OK, apparently the issue comes in an special case where a packet is received (started to being received) OK but at the end of the reception, the node has changed to a TX state.
Then, the packet is marked as "received while sending" but the node has already marked this frame as the next correctly reception. So it discards all receiving ones with no end.
It seems a bug and the possible workaround is adding these lines
if (!frame->getWasTransmitting()){
curSyncFrame = 0;
}
in the processSignalEnd function (Decider80211p file), inside the "(frame->getWasTransmitting() || phy11p->getRadioState() == Radio::TX)" case.
I'm not quite sure if this is a case that whether should happen or not, as a node should not send a packet while receiving.
Hope it helps.