1. How can I make my tests run faster?
2. How do I keep one consistent Signal Dictionary when there are several testers on the project?
3. Deleted
4. My C code does not compile under Visual Studio.
5. I set a breakpoint in Visual C++ but it is not hit when I run my test case.
7. Why did my node locked license stop working?
9. How do I know which TestCases failed when I view the Regression Report?
10. I have build errors when I upgraded MxVDev. What should I check?
12. When preparing an XML TestCase, how do I specify whether a signal is input or output?
13. How can I run only some of the test cases in a Scenario?
14. How can I easily determine the time between two transitions?
15. How can I add comments to specific points or features in a TestCase?
17. What considerations are there for naming TestCases and allocating them to Scenarios?
18. How do I upgrade a temporary floating license for MxVDev™ to a permanent one?
19. Why does the System-Under-Test crash when I perform a MxV Module Reset?
20. Which XCP commands are required in order for an XCP device to communicate with MxV?
21. Which CCP commands are required in order for a CCP device to communicate with MxV?
24. How do I transfer a fixed license back to Danlaw?
25. How do I transfer a floating license back to Danlaw?
26. When starting MxVDev™ I receive the error message “NETWORK: Reply from network driver is bad.”
27. How do I link test cases to DOORS requirements?
28. How do I install several versions of MxV?
29. How do I manage traceability of requirements to test cases?
30. Why doesn't MxVDev acquire a license when I access the PC remotely?
31. Why does my installation fail with the following message: "1: ALLUSERS property is not 1 – this MSM cannot be used for a per-user or fallback-to-per-user install."?
32. How can we change the width of the Signal Name field on the reports?
34. How do I enter standard waveforms – Sine/Saw tooth/Square wave, etc?
36. Deleted
37. Why do I have to rebuild the SUT when I install a new version of MxVDev™?
39. Why do I get build errors using Visual Studio Express 2008?
40. Is MxVDev™ able to work with other Code Coverage tools besides Bullseye?
41. What can I do if MxVDev™ will not uninstall because I do not have the original MSI package?
43. What is .Net and why do I need to install it to run the MxSuite™?
44. In our project we have C code similar to the following:
do
{
…
}while (condition == 0).
How do I prevent the code from hanging when being tested under MxVDev? |
47. I want to export my signal dictionary from one project to another. How do I do this?
48. What are the negative aspects with using a low "Test resolution"?
49. How is that we can observe time duration in-between two points of a signal?
50. What's the easiest way to determine what levels of the .NET Framework are installed on my computer?
51. What do I do if .NET 3.5 SP1 is not installed on my system?
52. How do I enter the middle dot (·) character?
53. How do I select multiple Signals in a TestCase?
See Performance Tuning.
By default the Signal Dictionary is called MxV.mxd and it is located in the MxVDev project folder.
•With release v3.10 and higher of MxVDev you can store the Signal Dictionary on a network shared drive
•From the main menu under Project Settings, you can change the path to the Signal Dictionary to point to the network drive.
•This allows all testers on a project to use the same Signal Dictionary simultaneously.
There are many reasons for this. Usually they are easy to solve. Some examples of the problems and their solutions are listed below:
•Keyword ‘far’ is not recognized – In the PC environment we do not need to use the compiler specific memory model keywords like near, far. Other keywords like interrupt are also not needed. In your global #defines source file add the following:
#ifdef MXVDEV
#define far
#define near
#define interrupt
#endif
Note that if you receive a new release of the application source code, you will have to merge in the changes so that you don’t lose the #ifdefs that have been added to your code.
Here are five things to check:
•Make sure that you have an Execution Model test case in the scenario (such as Task_5ms in the Door Turn sample). If this does not exist, no code in the SUT will ever be executed.
•Make sure that the test would actually cause the breakpoint to be hit. That is, the lines of code are caused to execute by the test that is being run
•When you build the SUT, make sure the active configuration is the Debug build
oOn the main menu of VC++ 6.0 select: Build->Set Active Configuration
•Visual Studio must be 'Attached' to MxVDev. This is achieved in one of two ways:
oYou can start MxVDev from the VC++ project. When you start MxVDev you must use the Build->Start Debug->Go command (F5) (not the Execute command (Ctrl F5)). Review the setting in Visual Studio for Project Properties->Debugging in the TurnDoor sample to see how your project should be configured.
oYou can start MxVDev and the Visual Studio projects independently, and then in Visual Studio 'Attach' to MxVDev (from the main menu select Debug->Attach to Process, then select MxRTE.exe).
•In Visual Studio there is a Project Property setting that should be set. From the Main Menu select Project->Properties. Select Debugging, and set Debugger Type to Native Only.
This could be done by setting up the Value Tolerances. A simpler approach in this case is just to set up the Signal minimum and maximum values. In the Signal Dictionary add an output signal and put the pointer label in the ‘‘C’ Variable Name’ field. Set the minimum and maximum value range of the signal to [1, 0xFFFFFFFF]. For an output signal, an out-of-range value is flagged as a failure.
There are a couple of things that can cause this:
•You deleted or modified files in the installation folder under the subfolder: ...\MicroMax\MxVDev\bin
•You changed the computer time to a time, different from the actual time, by more than 15 min. This will only cause a problem with temporary evaluation licenses
You must return the Fixed License to Danlaw, before we can issue the Floating License.
We will send you a zip file via e-mail, along with the following instructions for returning the license:
1.The zip file contains a single folder called LicenseTransfer. Unzip the zip file to a location on your c drive.
2.Launch MxVDev and go to Help->License.
3.In MxVDev License dialog, it should show that you have valid fixed license. If you are using floating license, STOP.
4.Click the “Next” button in License dialog, you will see “Transfer Out…” button is enabled.
5.Click “Transfer Out…” button.
6.The “Transfer License Out” dialog will show up. In this form, click button to select the LicenseTransfer folder in your C drive and then click “OK”.
7.If the license is successfully transferred out, the form will disappear (note that the LicenseTransfer folder may appear to be empty since the files created are system files, and may be hidden).
8.Zip up the LicenseTransfer folder and e-mail it back to Danlaw Support.
The Regression Report shows which Scenarios failed for a given regression run. For a given Scenario, click on the Scenario Log File link (the file has a .mxlog extension). The Scenario will be loaded into MxVDev, with all the actual results information, as it was when the test was completed. All the failed TestCases are shown, with the location of the failures highlighted. In addition the descriptions of all failures are available.
Note that you have to initially load the appropriate project in MxVDev.
The most likely cause is that the Visual Studio environment is not set up correctly. There is a small program you can run to set this up for you:
•First close any instances of MSVC and MxV you have open and then browse to where you installed MxV. The default location is C:\Program Files\MicroMax\MxVDev\
•Under the \bin directory there is a program called MxVSDK.exe. Run this program. (It is run automatically during installation of MxV v3.18.0 or greater)
oIt should configure MSVC6, MSVC 7.1, & MSVC 8.0 with Executable, Include, and Library paths to the following locations.
oExecutable: C:\Program Files\MicroMax\MxVDev\bin
oInclude: C:\Program Files\MicroMax\MxVDev\Harness\include
oLibrary: C:\Program Files\MicroMax\MxVDev\Harness\lib
oYou can check these paths are set, or set them manually by navigating as follows:
oMSVC 7.1 - Tools->Options->Projects->VC++ Directories
oMSVC 8.0 - Tools->Options->Projects and Solutions->VC++ Directories
You should also check the Project specific settings:
•C/C++, General
Remove any reference to the MxVDev\Harness from the include paths
•Linker, General, Additional Libraries Directories
Should now be blank (remove any reference to MxV\Harness)
•Linker, Input, Module Definition File
Should now be blank (remove any reference to .def files)
•Linker, Input:, Additional Dependencies
Should now be blank (remove all references to MxHarness.lib or MxVHarnessXX.lib)
These settings are set up globally in the IDE by running MxVSDK.exe.
For more information, see Visual Studio and MxVDev.
The MxVDev default is to use the Transition Element:
•Transition blocks give more flexibility for specifying tolerances
•MxVDev always saves to disk in this format at present
CSV lists in some cases will use less disk space, but our plan is to decide programmatically when it is appropriate to use this option.
The CSV list without the time field may use even less space still; however, the value in the CSV element must be provided. In this case the times will always have equal intervals.
In the XML Schema, the Signal entity has a required attribute called SignalType. It can take values of:
•Cmd - Input to the System Under Test (SUT)
•Exp - Expected Output from the SUT and
•Act - Actual Output from the SUT
Note: Our convention is that the words input and output always specify a data flow with respect to the SUT.
On the Scenario form, for each job that you do not want to run, edit the Job Properties and set the Run Count to zero.
Delta Times and Delta Steps are shown on the status bar of MxVDev at the bottom on the screen. The deltas are measured from the vertical green cursor and the mouse position. Times are shown as a range that corresponds to the width of a step.
You can add comments to any transition. Right-click on the transition, select Edit Transition, and enter a comment. Comments are marked by small orange dots at the base of the transition. When you mouse-over the transition, the comment is displayed. The comment also appears in Scenario log files.
The quickest way to create these files is from the command line. If you have to do one or two from the GUI, here are a few tips that will speed it up:
•On the main menu set Display Refresh Rate to 10,000
•Zoom out so you can see all of the test case
•Ensure ‘Limit run speed to Real Time’ is not set in Project->Settings->Execution
•Set the Repeat Count to zero for any jobs that just run periodic tasks. (If you just need a Command File, you don’t need to execute any code in the SUT.)
Here are some simple guidelines:
•As you create tests, add them to a scenario immediately so they will always be run when you do a regression test.
•Put several related tests in a single Scenario. (However, if you put more than 15 or 20 in a scenario it will become difficult to manage.)
•Put tests that verify a given feature or sub feature in the same scenario.
•Design test cases so that they can be re-used to set up a SUT state as pre-conditions for other test cases.
•You can usually re-use the same initialization and Execution Model test cases in many of your Scenarios.
•Use a naming convention to group related TestCases in the file explorer.
•Fill in the requirements traceability fields in the test case properties as you go. It is hard to re-create this traceability information at a later date.
•Run the regression test daily to ensure that nothing got broken by changes to the SUT code or the AppIF.c code.
This is done using the MxVDev License Manager from any desktop system that has permission to access the MxVDev License(s).
1.Launch the MxVDev License Manager.
2.Select the Status Tab to see who is using MxVDev and how many days are left on your temporary license (just to be sure you are about to update the appropriate license)
3.Select the License Tab and ensure that the License File Location is set to the path of the license that you want to update.
4.Copy the Site Code shown and send it to mxsupport@danlawinc.com. (Note that the next available Site Code is the same every time that the License Manager is run until a valid Site Key is entered.)
5.MicroMax will send you the new Site Key. Paste it in the appropriate field and click Validate.
6.Select the License tab and verify that the license has been installed correctly and has the appropriate user count and expiry date.
If you do a Module Reset on an MxVMC, you need to run the Init function (void SUT_Init(void)) in the same MxVDev step. If you don’t, it is like re-starting the micro, and starting the application in the micro without initializing the micro.
Run the Init function with a task Signal in the same step and immediately below the Module Reset, as follows:
The following XCP commands must be implemented by an XCP slave. The first few commands provide information about the ECU. The next group of commands is needed to perform data transfer from/to the ECU using DAQ and STIM lists (this way of data transfer is the fastest and is typically used to read/write measurements). The last group of commands also performs data transfer but with an added overhead (this way of data transfer is typically used to read/write calibration data since they don't change often).
CONNECT
DISCONNECT
GET_STATUS
GET_COMM_MODE_INFO
CLEAR_DAQ_LIST
SET_DAQ_PTR
WRITE_DAQ
SET_DAQ_LIST_MODE
GET_DAQ_LIST_MODE
START_STOP_DAQ_LIST
START_STOP_SYNCH
GET_DAQ_PROCESSOR_INFO
GET_DAQ_LIST_INFO
GET_DAQ_EVENT_INFO
FREE_DAQ*
ALLOC_DAQ*
ALLOC_ODT*
ALLOC_ODT_ENTRY*
SET_MTA
DOWNLOAD
UPLOAD
* Optional if Static Daq Lists are implemented.
See CCP/XCP.
The following CCP commands must be implemented by a CCP slave. The first few commands provide information about the ECU. The next group of commands is needed to perform data transfer from the ECU using DAQ lists (this way of data transfer is the fastest and is typically used to read measurements). The last group of commands also performs data transfer but with an added overhead (this way of data transfer is typically used to read/write calibration data since they don't change often).
CONNECT
DISCONNECT
GET_CCP_VERSION
GET_DAQ_SIZE
SET_DAQ_PTR
WRITE_DAQ
START_STOP
START_STOP_ALL
SET_MTA
DOWNLOAD
UPLOAD
See CCP/XCP.
You can force MxVDev to use a particular version of Matlab/Simulink by providing the path to the Matlab Executable File (usually at bin\win32\matlab.exe) in the properties of the Simulink transform. This ensures that the specified version of Matlab/Simulink is used by MxVDev when multiple installations exist on the same machine.
The message is expected – You are trying to debug your SUT, not MxVDev. There does not need to be MxVDev debug information available.
Just check "Don't show this dialog again" and click Yes.
Danlaw will send you a zipped file. It contains a folder with a single file in it (the file may be a hidden file on your system). This folder is a placeholder to hold the license to be returned.
•Start MxVDev, select Help‑>License.
•Extract the zip file to any location accessible to the system with the MxVDev license. If you unzip it to the root of your C drive you will end up with a folder c:\MxVLic.
•Click Transfer Out, enter the path c:\MxVLic, and click OK.
•Verify that the fixed MxVDev license is no longer available on that computer.
•Re-zip the folder c:\MxVLic, and e-mail the zip file back to Danlaw.
Danlaw will send you a zipped file. It contains a folder with a single file in it. (The file may be a hidden file on your system). This folder is a placeholder to hold the license to be returned.
1.Start the MxV License Manager.
2.Extract the zip file to any location accessible to the system running the MxV License Manager. If you unzip it to the root of the C drive you will end up with a folder c:\MxVLic.
3.Click Transfer Out, enter the path c:\MxVLic, and click OK.
4.Verify that the floating MxVDev license(s) is no longer available.
5.Re-zip the folder c:\MxVLic, and e-mail the zip file back to Danlaw.
The installation of the Crypkey service has become corrupted (this is rare). To fix this problem the Crypkey software has to be removed manually, then reinstalled.
•Stop the CrypKey license service
•Delete the following files in the WINDOWS\SYSTEM32 directory:
ckldrv.sys
crypserv.exe
esnecil.ind
•Delete the following files in the WINDOWS directory:
ckfresh.exe
ckconfig.exe
setup_ck.dll
setup_ck.exe
•De-install MxVDev
•Reboot your system
•Re-install MxVDev (this will also re-install Crypkey)
Using DOORS, create a URL for each requirement (contact Telelogic Support if you don't know how to do this). Note that MxVDev, DOORS, and the default browser (usually Internet Explorer) are assumed to be installed on your PC and the URL for the requirement must be accessible using the default browser. To provide traceability from MxVDev back to DOORS, do the following:
1.Open the test case associated with the requirement from MxVDev.
2.Using the toolbar, select TestCase -> Properties.
3.Select the Associated Requirements tab.
4.Select "Add" or "Edit" and modify the name of the Source Document and Description.
5.Enter the URL (hyperlink to DOORS requirement) in the Unique Requirement Reference field.
You can install a new version of MxSuite without removing previously installed versions. See Changing MxSuite Versions.
Within MxVDev, provide the traceability references directly to the test cases or test scenarios.
For test cases, select TestCase->Properties from the Menu Bar, Select the Associated Requirements tab.
For scenarios, select Associated Requirements tab from the Scenario window.
Three fields are provided for traceability:
•Source: Designates where the requirement can be found. Often, this will be the actual name and version of the document, or the name of a database.
•ID: Designates the identifier (a string, object id, or number) of the specific requirement, design element, test case, etc.
•Description: Can contain a keyword, actual verbose description, or any other useful traceability info.
When you generate the regression test report, the traceability results will be contained in it.
See Requirements Traceability.
MxVDev installed with a fixed license is for use on a single PC. Remotely accessing the PC is attempting to have MxVDev work as a floating license installation.
To access MxVDev remotely, the MxVDev license server will need to be installed and a floating license will need to be used. The license server can be installed on a separate PC on the network or directly on the PC that is to host MxVDev.
Please refer to Installation and Licensing.
To install MxVDev, you need to have Local Administrator privileges and no Custom Policies in place that prevent All-User installations.
When you save a test case the layout is saved also. Layout includes form size and position on the screen. It also includes the width of the field that shows the Signal Name. The saved width of the Signal Name is used when generating the images for the reports. To demonstrate this:
1.Adjust the width of the Signal Name field on a particular test case.
2.Click the Save All button on the toolbar.
3.Run a regression Test.
4.Navigate to the image of the test case.
5.The width of the Signal Name field will be the same as when you last saved the test case.
Handler Functions are invoked any time an Input or Output Signal changes.
•The Handler Functions are invoked once per Signal Transition, for each Transition that is transmitted to or from the SUT
•Apart from explicit changes to a Signal in a TestCase, all Input Signals receive an additional Transition for:
oMxVModuleReset – This is to reset all the Inputs in the SUT Harness to the value just prior to the reset. (If an input to a module is true just before the module is reset, it normally would be true as the module comes out of reset)
oInputSignalReset – This resets the Input Signals back to their Initial Value stored in the Signal Dictionary
•In summary, your Handler Functions are invoked if the associated Signal changes, or if either MxVModuleReset or InputSignalReset occur.
On the Time axis, the data for a Signals Profile is partitioned into DataBlocks. A DataBlock can have a Signal Generators (SigGen) as its Data Source. To set up a Signal Generator:
1.Right Click on the Plot Area of a Signal
2.Select DataBlock->Properties
3.Select the Data Source tab
4.Select the Signal Generator radio button
5.Fill in the parameters for the selected SigGen
6.Click the Apply button
Note: You can also write your own simple or arbitrarily complex SigGen in C#.
See Signal Generator.
Yes.
In MxVDev, the data for a Signal can be partitioned into discrete ranges on the time axis. These are called DataBlocks. 'Don't Care Ranges' are implemented using DataBlocks.
When you 'Accept Results' you have a choice. You can accept for the whole Signal or you can accept for individual DataBlocks.
•Signal Accept Results Method
oAccepts all the data from the start of the TestCase to the stop point of the TestCase
oEnsure that the Signal is selected, and click Accept Results on the toolbar, or position the mouse pointer over the Plot Area of the Signal, right click and select Signal->Accept Results
•DataBlock Accept Results Method
oAccepts results just for the selected DataBlock
oTo accept Results for a DataBlock, position the mouse pointer over the Plot Area of the DataBlock, right click and select DataBlock->Accept Results
If you want to avoid 'Accepting Results' on a 'Don’t Care Range', just Accept Results individually for the DataBlocks that you are interested in.
When we release MxVDev there are two pieces that change versions:
•MxVDev – The GUI, and
•The VMC Harness – Virtual Micro-Controller libraries stored in C:\Program Files\MicroMax\MxVDev\Harness
To test your code with a particular version of MxVDev, you need to build the SUT using the corresponding libraries that were installed in the Harness folder. When you install a new version of MxVDev, you need to rebuild the SUT to ensure the SUT and GUI are consistent.
Every version of MxVDev that we release is checked to ensure that the results of any scenario will be identical to previous result sets. Every night we run many regression projects from many years back to ensure that the latest version generates the same results as prior versions.
We can have several Signals refer to the same pattern. It is done through an External Data File. There are two steps:
1.Save the pattern to an External CSV File:
a.Right Click in the Plot Area of the Signal, and select Signal->Save to External Data File.
b.Use the Browse button to be sure of the location that the file is saved.
2.Reference the External CSV File:
a.For the Signal that you want to reference the External Data File, Right Click in the Plot Area.
b.Select DataBlock->Properties, and choose the DataSource tab.
c.Select External for the Data Location.
d.In the Data Source File field enter or browse to the CSV file created in the step above.
I get the following error:
fatal error C1083: Cannot open include file: 'MxVuC/mxv_uC.h': No such file or directory
This problem is because the search directories have not been set up.
•In Visual Studio 2008 Express, from the Main Menu select Tools->Options, then Projects and Solutions->VC++ Directories
oAt the top right in the drop down box select Include Files
oUse the New Folder icon to add the path: C:\Program Files\MicroMax\MxVDev\Harness\include
oAt the top right in the drop down box select Library Files
oUse the New Folder icon to add the path: C:\Program Files\MicroMax\MxVDev\Harness\lib
In summary, your Handler Functions will be invoked if the associated Signal changes, or if either MxVModuleReset or InputSignalReset occur.
There should be no problem with using other Code Coverage tools. Some coverage tools instrument the source code at compile time, some instrument the exe file after build.
•Compile Time Instrumentation – The tool will probably need to integrate well with the version of Visual Studio that you use
•EXE Instrumentation – This should work as long as the coverage tool can instrument a Windows DLL (the SUT file is a Windows DLL)
One potential issue that you should be aware of: When an instrumented SUT is in use by MxVDev, it may also be in use by the coverage tool. We have seen that the MxV Module Reset does not work properly if another process is also using the SUT DLL. This is because the DLL cannot be unloaded by MxVDev. For Bullseye the solution is to set the environmental variable COVAUTOSAVE = 0.
There is a useful utility called msizap (which can be found from the Microsoft platform SDK) to remove the product from the install applications table.
msizap TW! {productcode} (where productcode is the product code associated with the installed program’s MSI file)
http://msdn.microsoft.com/en-us/library/aa370523(VS.85).aspx provides full information on usage
If you need help finding the product code it can be found by using Orca (also can be found from the Microsoft platform SDK). In Orca, just click the properties tab, look for Product code.
msizap can also be used with the version of the msi package windows keeps after install. However, since they are not labeled properly, you must know when the install occurred. The windows copy of the packages can be found in the %windir%\installer. (where %windir% is the windows directory) Once this is known you can use the following:
msizap TW! {msi package}
You can use DataBlocks and Tolerances to allow a range of acceptable values. Suppose you have a Signal that has a value range from 0 to 10, and in a test you don’t care what the value is for the first two seconds, and after that you want the value to be greater than 5.0.
•Select a Range from 0 through 2.0 seconds. Right click and select Results Check Off. You will see that the Signal Plot Area is now divided into two DataBlocks. It no longer matters what value the Signal has in the DataBlock from 0 to 2.0 seconds. All values will pass.
•On the second DataBlock set the expected data pattern to a horizontal line with value of 5.0. Right click on the plot area of the second DataBlock, choose DataBlock->Properties->Pass/Fail Criteria->SignalValue. Click Override, set the lower tolerance to 0 and the upper tolerance to 5.0. Now all values between 5.0 and 10.0 will pass.
You might also consider Triggers for detecting that a threshold has been crossed. See Creating a Trigger.
The .Net Framework refers to a set of libraries from Microsoft that are used to create Windows applications. Many Windows applications use the .Net libraries so they may already be installed on your computer.
•To see if they already installed, refer to What's the easiest way to determine what levels of the .NET Framework are installed on my computer?.
•You can find a download link at: http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=5b2c0358-915b-4eb5-9b1d-10e506da9d0f
do
{
…
}while (condition == 0)
MxVMC (the Virtual Micro-Controller) does not allow for concurrent/preemptive execution of tasks. It executes one task at a time, meaning it will execute SUT_Tick (for example) and when it returns control to MxVDev, MxVDev executes the next task in line. With this in mind, there can be no code that loops forever waiting on a condition to be set to true by external tasks (such as interrupts).
We may find such code constructs in embedded systems in two cases which we will classify as Short Wait and Long Wait.
Short Wait
We sometimes find such loops where we are waiting for a hardware register to change and the wait period is expected to be just a few microseconds. In this case it is typically acceptable to do the following:
do
{
....
#ifdef MXVDEV
condition = 1;
#endif
}while (condition == 0)
In this case the loop will exit immediately when executing in the test environment.
Long Wait
In this case, the loop is used to synchronize two tasks without an operating system. It is often inadvisable to wait in such loops for long periods of time. (Watchdogs may time out, CPU cycles are wasted, etc). The preferred code construct is to have the tasks communicate using a state variable. Task1 would set the state variable, thus allowing Task2 to move to the code that is after the loop. The code may be re-factored to look like the following:
void Task1(void)
{
if (…)condition = 1;
}
void Task2(void)
{
switch (State)
{
case Before:
//…;
break;
case Loop:
if (condition <> 0 ) State = After;
break;
case After:
//…;
break;
}
}
There is no hard limit. Here are a couple of features that help you manage larger Test cases:
•The Auto-Hide feature on the TestCase toolbar helps you manage larger TestCases by hiding signals that do not change.
•On Job Properties there is an AutoAdd checkbox. Enabling this feature causes MxVDev to monitor Signals that are not in the TestCase. If any Signal changes it is added to the test automatically. This means you do not have to keep Signals in a TestCase if they should not change. They will be added automatically and the test will fail if the Signal changes.
There are several things that you could consider:
•Import the CAN DBC file
a.Put CAN signals and messages in the TestCases to interchange CAN data with the SUT
b.Have MxVDev simulate the other nodes on the bus (as CANoe might do). Signals in test cases are automatically packed into the CAN messages, and messages are auto-transmitted based on DBC file rules.
•Programmatically create test cases (.mxc files) in C# that would put complex sequences of CAN messages on the virtual CAN bus.
•Write a C# transform that would "close the loop" with CAN messages. It would receive CAN messages and, based on the data that was received, it would transmit other messages on the bus. In this way we would actively simulate/model another ECU node.
•Connect the virtual CAN bus to a real CAN bus using a network interface card, and have actual CAN traffic received by your SIL entity running in our VMC.
•Import Vector CAN traces and play them onto the virtual bus.
The Signal Dictionary is stored in the file with .mxd extension. It stores the Enums also. You can copy it from one project to another. You can set a project to use a particular dictionary under Project Settings.
Your choice of Test Resolution it is really a tradeoff between accuracy and performance. Things may get slow if you make Test Resolution too small. It relates more to Continuous Signals rather than Discrete or Message Signals:
•Suppose Test Resolution is 1ms. If you create a ramp, or a sine wave there will be a transition at every millisecond. If the ramp/sine wave extends for 30 minutes you will have 30*60*1000 transitions. There is a lot of data and things will slow down.
•Test Resolution also determines how we Accept Results. If we sample Actual Results at 1ms, and the Test Resolution is 10ms, we will capture only every 10th transition when we 'Accept Results'. If the profile of the Actual Results is smooth and the tolerances are not too small this works fine. If you need to capture the shape more precisely you need to set the Test Resolution down to 1 ms. We will capture all the data points and store them in the test case file.
One way: From the Main Menu select View‑>Transition List. This will show the time and value of all the transitions for a Signal in a TestCase. Once the Transition List is displayed, mouse over the plot area of the Signal of interest. Note that there are two Transition Lists displayed, selectable by a tab at the bottom left (usually). Specified Transitions are those for input signals, or expected output values. Actuals are for actual measurements (red dots).
A second way: You can get a rough measure by clicking at a point on a Signal. This places the green cursor. Now as you move the mouse to the left or right, on the Status Bar at the bottom you will see the Delta T. This is the time from the Green Cursor to the location of the mouse. You may need to zoom a little to get a good measure of time.
The easiest way to determine which versions of .NET you have on your machine is to check under the Add/Remove Programs control panel item (Programs and Features in Windows Vista and later). You may want to double check there to make sure you have .NET 3.5 Service Pack 1 installed on your system. Windows 7 comes with .NET 3.5 pre-installed, though you still need to make sure you have the Service Pack 1 update.
You can download the .NET 3.5 SP1 installer from Microsoft's website. If you already have .NET 2.0 installed, Microsoft recommends uninstalling that version first since .NET 3.5 inherently includes .NET 2.0.
The middle dot character is a UTF-8 character (U+00B7). Use this procedure to enter it from a keyboard:
1.Be sure the Num Lock is on.
2.Hold down the Alt key.
3.Press 0183 on the numeric keypad.
4.Release the Alt key.
You can also copy the dot from here (·) or elsewhere.
In the MxSuite, the middle dot character is used in message-based signals to separate the Message Name and the Field Name.
•To select non-consecutive signals, hold down the Ctrl key and click on the name of each signal.
Two Signals Selected
•To select a group of consecutively listed signals, hold down the Shift key and click on the first and last signal of the group. You can use the up and down arrows in the Pick Signals dialog to arrange the signals into a consecutive group.
•To select all the signals, press Ctrl-A.
Visual Studio is looking for a PDB file that is used for internal debugging of the MxSuite. Select "Don't show this dialog again" and click Yes. See Debugging SUT Applications Using MxVDev and Visual C++.
Another workaround is to use Method 1 for debugging.