I am trying to disable a particular message of a node from sending default values available in dbc file, and through capl i need to transmit new(dummy) values.
I found the function ILNodeControlStop(), which blocks the node completely, but i want to block only one message and not block the entire node.
How to disable an ECU node from sending a message from IL?
You can use
ILDisableMsg(<messageName>);
to disable the message and
ILEnableMsg(<messageName>);
to enable it again.
All this assuming, that you are using the CANoe interaction layer.
Related
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
I want to send a Janus frame to specific node not a broadcast message in a 4-node network, how to do that? and how to calculate the transfer time to that node?
The JANUS spec doesn't define node addressing, and so the standard JANUS frame isn't able to support to and from fields. You'd need to put in this information at an application level in the cargo (data) or the appData field, and use it at the receiving end.
Assuming you are using txJanusFrameReq, you can use the to field to specify the destination node address, just like you would do with txFrameReq. (E.g. TxFrameReq(to: host('B')))
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 need to emulate a radio communication network composed of N nodes, with these properties:
nodes either send then receive data, or receive then send data, but not at the same time.
data sent over-the-air are received by all nodes which are in receive mode at that time.
if two or more nodes sends data simultaneously, data are lost.
there is no time synchronization among nodes.
In Go, if I use a channel to emulate the transmission media, data are serialized, and only one receiver gets the data, not all of them.
Also, I cannot think of a way to "ruin" the data if two sender try to send at the same time. Whether I use a mutex or not, one of the sender will successfully get its message sent.
Why don't you create a publisher and subscriber module using Golang Channels.
Create a centralized queuing system where all your sender and receiver nodes register themself. If any node sends the data it will go to that module and from the sender's list, it picks the senders channel and starts writing on it. The same applies to receivers also.
You have to create one channel per node and register it to a central pub/sub module. This will definitely solve your problem.
Collector node issue: I am currently using collector node to group messages (XML's). My requirement is to collect messages till the last message is received. (Reading from file input)
Control terminal: I'm sending a control message to stop collection and propagate to next node. But this doesn't work. As it still waits for timeout/quantity condition to be satisfied.
MY QUESTION: What condition can I use to collect messages till the last message received?
Add a separate input terminal on the Collector node that is used to complete a collection. Once you send a message to the second terminal, the collection is complete and propagated.
The Control terminal can be used to signal the Collector node when complete collections are propagated, not to determine when a collection is complete.
A collection is complete when either the set number of messages are received or the timeout is exhausted for all input terminals.
So if you don't know in advance how many messages you want to include in a collection, you have 3 options:
Set message quantity to 0 and set an appropriate timeout for input terminals.
This way the node will include all messages received within the time between the first message and the timeout value in the collection.
Set a large number as message quantity and use collection expiry
With collection expiry, incomplete collections can be propagated to the expiry terminal, but this will work essentially the same as the previous method.
Develop your own collector flow
You can develop a flow for combining messages using MQ Input, Get and Output nodes, keeping intermediate combined messages in MQ queues. Use this flow to combine your inputs and send the complete message onto the input queue of your processing flow.