How can we check the response of UDS message through CAPL? - capl

I have written a basic program to send a UDS message in CAPL, But I don't know how to take the response inside the testcase function.
Below is the code snippet
includes
{
}
variables
{
message 0x639 read;
}
void maintest()
{
tc1();
}
testCase tc1()
{
read.dlc=0x08;
read.byte(0)=0X02;
read.byte(1)=0x10;
read.byte(2)=0x03;
output(read);
testStepPass("OK");
}

As mentioned in the previous comments, it is recommended to use the Diagnostic Features.
If you wish to use raw frames, then there is a function for waiting for the response message.
TestWaitForMessage(0x649,100);
TestGetWaitEventMsgData(res_msg);
The res_msg will be having the byte values of the response.
You can access it by res_msg.byte(0).

why don't you use diagnostic module from CANoe?
You can add your own diagnostic console under Diagnostics (or Diagnostics & XCP) tab -> Diagnostic/ISO TP and set up your own console (you need to configure things like target address, diagnostic layer etc.).
After that all the functions needed for CAPL you can find in help press F1 in CAPL Browser -> CAPL Functions -> Diagnostics CAPL Functions.

Related

CAPL: On Message Not Recognizing Database

Programming for CANalyzer in the Vector CAPL Browser, I can start typing "on message CAN4..." and it will auto complete things for me. I can see the messages. But after selecting a message, it always yells at me with "Expecting message name or identifier. Database missing?" as if it has no idea what I just put in even though it helped me put it there. What is the proper format for this? Is it different since I'm using ARXML instead of DBC? Is it just not compatible?
on message CAN4::Something_PDU // Auto-completes this but gives the error
{
}
on message CAN4.Something_PDU // Never auto-completes this and also doesn't work
{
}
on message CAN4::Something_PDU::Something_Auth // Auto-completes but not sure that's what I want and also doesn't compile with same error.
{
}
What is the right way and/or why doesn't it recognize the database despite its obvious ability to auto-complete? So confused!
I just faced a comparable issue when trying to get called by incoming ethernet signals. They are also defined in an *.arxml, in my case. However, the behavior of the Vector CAPL-Browser was exactly the same as you described.
I figured out that replacing on message with on signal does the trick and the script can get compiled:
on signal Something_Signal // autocompletion works and compiles
{
}
on signal Eth1::Something_Signal // autocompletion doesn't work but compiles
{
}
there is another way to do this: goto Windows symbols on the right panel in CAPL Editor >
try to find Something_PDU > drag and drop PDU_Name on your Code after on message
the CAPL event on message should be use with name
try use
on message Something_PDU
instead of
on message CAN4.Something_PDU

On Substrate ink! How can I get Debug information?

I want to get Debug Information.
I implemented this code,but I can not get.
Please tell me how can I get Debug Infomation.
#[ink(message)]
fn set_test_data(&mut self, value: String) {
ink_core::env::println(value);
self.test_data.set(value);
}
Those error messages are printed to the console. Please note that you need to supply the following command line arguments to your node in order to make this happen:
--dev: Use the dev chain spec. You should already be using that.
-lruntime=debug: Increase the log level for runtime generated messages.
It's now in the ink_env crate:
ink_env::debug_println!("{}", "Hello log");
The FAQ entry on this is here:
https://paritytech.github.io/ink-docs/faq/#how-do-i-print-something-to-the-console-from-the-runtime

How to print out tracing message in Substrate runtime development

When working on Parity Substrate runtime development, how can I print out debug message for tracing and inspecting my variables?
Both of the above answers are correct in their own sense/time. Here's a more accurate overview:
runtime_io::print("..."); has been moved. You can now use the same function from sp-runtime::print(). These will be visible in a log target named runtime. So you'd have to do RUST_LOG=runtime=debug. You are still calling into sp_io under the hood though. Also, note that frame_support is re-exporting this for you. Most pallets need frame_support anyhow and this maeks the usage easier.
If you want to compile for wasm and native, and want prints only for native execution, use sp_std::if_std!{} macro.
Finally, you can use frame_support::debug module. This module provides wrappers around the above two to make the usage easier and more rust-like. Similar to a normal logger, you can use debug::native::warn!(...) etc.
A final useful tip is to: when possible, you can just bloat your code with println! and do SKIP_WASM_BUILD=1 cargo run [xxx]. This is helpful when you are developing and want quick debug prints without any of the setup explained above.
You can also use the if_std! macro included with sp-std:
https://github.com/paritytech/substrate/pull/2979
if_std! is a feature gate that should only be run when std feature is enabled.
Example
sp_std::if_std! {
// This code is only being compiled and executed when the `std` feature is enabled.
println!("Hello native world");
}
This is better because you can println variables and stuff rather than simply printing a string.
As a newcomer to Substrate development, the most direct way I found is with runtime_io::print().
Example:
use runtime_io::{ self };
decl_module! {
pub struct Module<T: Trait> for enum Call where origin: T::Origin {
fn deposit_event<T>() = default;
pub fn my_func(origin) -> Result {
runtime_io::print("Hello World");
Ok(());
}
}
}
The message will then appear in the console. Pay quick attention to it as it is constantly scrolling.
For a complete example, refer to the TCR tutorial example in github.
you can use the log crate, add it to your cargo.toml and use it like this:
log::info!("hello {}",substrate);
source : https://docs.substrate.io/test/debug/

Calling XGetErrorText() from X11 error handler

Is it safe to call XGetErrorText from a error handler set by XSetErrorHandler?
E.g.
int errorHandler(Display *dpy, XErrorEvent *err)
{
char buf[BUFLEN];
XGetErrorText(dpy, err->error_code, buf, BUFLEN);
printf("%s\n", buf)
return 0;
}
XSetErrorHandler(errorHandler);
I'm asking because the man page says you should not call any functions (directly or indirectly) on the display that will generate protocol requests but it does not tell if XGetErrorText does.
XGetErrorText doesn't generate any server traffic. It's not supposed to: the server doesn't know your locale, for example, and cannot supply localised messages. XLib can, and indeed does with a couple of local Xrm database lookups.
The source code of XGetErrorText can be viewed e.g. here. We can see that XGetErrorText calls XGetErrorDatabaseText, and this latter function is not even using its dpy parameter.
Each X extension provides its own error-event-to-error-string translation function. This function does accept a dpy parameter, but, just like XGetErrorDatabaseText is not supposed to use it too generate any server traffic. This error-handling function is by default generateed by the XEXT_GENERATE_ERROR_STRING macro here, which just encapsulates another call to XGetErrorDatabaseText.

Debugging Erlang Webmachine resource functions

I'm trying to learn how to write Erlang Webmachine resources. One resource throws an error, but I can't tracking it down. The error message in the crash report does not provide enough information.
Is there a way to test these functions in the Erlang shell?
Most of the functions in the resource require request and context parameters. But I don't know how to simulate these parameters in the browser.
Example code below.
Thanks,
LRP
Example code:
I'm thinking specifically of functions like:
content_types_provided(RD, Ctx) ->
Path = wrq:disp_path(RD),
{[{webmachine_util:guess_mime(Path), generate_body}],
RD, Ctx}.
But my current bug is in the init function.
This works...
Dispatch rule:
{["blip"], zzz_resource, []}.
Init:
init([]) -> {ok, undefined}.
to_html(ReqData, State) ->
% {"<html><bodoy>Hello, new world</body></html>", ReqData, State}.
{test:test(), ReqData, State}.
But this throws an error:
Dispatch:
{["static"], static_resource,[]}.
Init:
init(_) ->
DocRoot =
case init:get_argument(doc_root) of
{ok, [[DR]]} -> DR;
error -> "doc_root path error"
end,
{ok, #ctx{docroot=DocRoot}}.
=ERROR REPORT==== 4-Aug-2011::10:54:56 ===
webmachine error: path="/static"
{error,function_clause,
[{filename,join,[[]]},
{static_resource,resource_exists,2},
There are a lot of layers to this answer depending on what you want to see and how deep down the rabbit hole you want to go.
Let's start with the easy stuff:
The error you are getting tells me that a call to static_resource:resource_exists/2 resulted in a call to filename:join/1 which failed because it was passed [] as its argument. That should help you track down the issue.
Recommended reading: errors-and-exceptions
A crude way to track down errors in any language is just to add print statements at strategic loctations. In this case you can use io:format/2 or erlang:display/1 to display whatever you want to the console. For example:
...
erlang:display("I'm inside resource_exists!"),
StuffToJoin = ["foo", "bar"],
erlang:display(StuffToJoin),
filename:join(StuffToJoin),
...
Just reload the page you should see the value printed in the console (assuming the appropriate function was called as part of the reload).
If you want to manually test a resource (like in a unit test) you can do something like the following:
Headers = [{"Host", "mydomain.com"}, {"user-agent", "Firefox"}],
Context = [],
Path = "/static",
ReqData = wrq:create('GET', {1,1}, Path, mochiweb_headers:from_list(Headers)),
static_resource:resource_exists(ReqData, Context)
If you want a deep look at how to debug webmachine, you can read this. You can get pretty far with the above, but doing a full trace can be helpful if you need to see the decision graph.
In addition to the various techniques David has suggested, you should also learn to use the dbg module. It is incredibly powerful and lets you trace functions and modules in real time.
As an example, for your particular case, suppose you want to trace all the functions in static_resource module :
..
1> dbg:tracer().
{ok,}
2> dbg:p(all,[c]).
{ok,[{matched,nonode#nohost,25}]}
3> dbg:tp({static_resource, '_', '_'}, []).
{ok,[{matched,nonode#nohost,5}]}
...
after which you will see a printout (includs all the function parameters in the function call) whenever static_resource module is invoked anywhere.
A full description of dbg is beyond the scope of this small answer space. I recommend O'rielly's Erlang Programming book. Chaper 17 has a really awesome write up and tutorial on how to use it dbg and its various trace features.

Resources