We have a possible conflict with another NDIS LWF driver, and was wondering if there is any concept similar to minifilter's altitude in NDIS LWF, so we can change our altitude to see if it resolves the issue or not.
We sometimes do the same thing with our minifilter, when there is a buggy minifilter below us that doesn't properly handle some of the requests that we generate. So I was wondering if there is anyway we can change our altitude and go above the possible problematic LWF, thus causing that driver to not receive our self made Indicated NBLs, to see if it solves the problem or not.
The way to change the order of LWFs is to change the FilterClass. If two LWFs have the same FilterClass, then their relative order is unspecified.
Related
According to the docs there is no reference of check panicking in any situation, but I would like to know if there is any edge case where this method could panic rather than returning false.
AFAICS, there are currently two cases where check() may fail:
The path leads to a cycle (see https://github.com/onflow/cadence/issues/2264)
Not sure: The code/type of the stored value is broken and cannot be loaded
Please feel free to open an issue in the Cadence repository if you think this should be changed, and especially why. Thanks!
I'm implementing a model in which many transport (Transport fleet, Material Handling library) move in the same network.
I've got some limited access paths ( limited to 1 transport).
The intersection between two or more path are nodes; in this way if a path is already occupied it will stay in the node until the path is free again.
The model seems to run until some transport get stuck (see screenshot).
At the moment Transport are able to resolve collision, but if the Resolve collision parameter is false then when transports get stuck a collision is detected.
I think transport cannot choose who can be the first to can cross the path (my thought, any suggestion is appreciated).
It is not a constant problem, it can happen at different times of the one year simulation or not happen at all.
What's the problem? How can I solve it?
Thanks
Transport stuck image
The problem is that the underlying algorithms cannot possibly work for any situation or foresee any eventuality.
Either you use the build-in resolution or you have to apply custom intelligence, route-finding and decision-making, which is possible but not trivial :)
We have a PLC application that has been created in GXWorks3.
We're using an IQ-F FX5U-32MR/DS with two analogue components:
We're able to run our very simple program on the simulator and are having no issues, however when writing the changes to the PLC, we get the following error:
We can't find where this parameter lives, and where to set it. According to the manuals, we think these means the set value is out of range, but we're not sure where the range is defined.
What could be wrong with this parameter, and how do we change it?
The problem was due to the firmware on the FX5. The FX5-8AD we have attached requires version 1.5+.
The options are :
Indexed addressing
Base register addressing
PC relative addressing
Indexed and Base register addressing both work by adding the content of their respective register (Index / Base register) to the address mentioned in the address code.
[Though the subtle difference is Index register has its content as "index" of the array while the Base register has its content as "base" address of the array]
To make the code relocatable, only the content of the Base / Index register needs to be changed, but that too can only be accomplished by executing some additional code.
PC relative mode just references the other instructions relative to the current PC contents.
So, is option 3 the best answer ?
Thanks !!
There are multiple parts:
- Data: this is about loading values that are in a binary
- Code: this is about jumps and calls
Data doesn't matter much. Code is more interesting.
In the absolute case you call . You write the code so is right most of the time. If it is not, the loader patches it right there in the code.
In the relative case, you have to call which then calls So one extra hop.
In the end 3 is more flexible but might have a small runtime overhead.
Another reason why PC relative all the time can have extra costs is that the PC distance might not be the whole address space.
Absolute addressing can be a small optimization. But also costs more to start when things go wrong.
I have an xPC target application that talks to a device over RS-232. I am using the xPC serial block for this.
To talk to this device I first have to start at a default speed, say, 9600 bps, request a change of speed to, say 57600 bps, then change the speed on my side to match it.
The problem with the xPC block is that it forces you to choose a specific speed before running, and can't change it at run time. Is there a way/trick/hack to do this?
Here is my take so far. I don't think it can be done using existing Simulink blocks. I think I am going to have to take the xpcserial C code that comes with Matlab, take the code that sets the RS-232 speed, and wrap it in my own S-function.
I agree with you: I don't think it can be done, I'm afraid.
On further reflection, I've realised that in my xPC system, I get a compilation warning telling me that the blocks I'm using don't support sample time changes during runtime; this implies that it's not impossible in general…
Ian,
What I've done before on this stuff is just modify the registers behind XPC target's back. It's ugly, but xPCTarget is ugly in the first place.
Try modify Line Control Register and set the divisors directly -- all you need is the serial port IO address, and you know that.
It's worth a shot anyway, you're going to have to do it anyway.