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.
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 have "unmatched" flowfiles in a queue. Is there any way to transfer these flowfiles into another queue?
EDIT:
WITH #Andy's SUGGESTED SOLUTION - #RESOLVED
There isn't a way to directly transfer between queues because it would take away the meaning of how those flow files got in the queue. They have to pass through the previous processor which is making the decision about which queue to place them in. You can create loops using a processor that does nothing like UpdateAttribute, and then connect that back to the original processor.
Bryan's answer is comprehensive and explains the ideal process for on-going success. If this is a one-time task (I have this queue that contains data I was using during testing; now I want it to go to this other processor), you can simply select the queue containing the data and drag the blue endpoint to the other component.
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
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
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.