Issue
When using pydnp3 master station to query data from outstation, the measurement value can only print out at terminal, and there is no public interface method to retrieve measurement value in a clean way. i.e., the ScanRange method returns None (instead of the measurement value.)
Observations
Note that the version used to bind pydnp3 0.1.0 is outdated (2019).
The pydnp3 author seems to know that there is no measurement-retrieval entry point.
img1
The object that handle measurement processing (one kind of SOE) seems to be SOEHandler. However, there seems to one SOEHandler available and it only print measurement to the terminal(console.) Note: PrintingSOEHandler class is a binding from c++ binary. (i.e., __pydnp3_opendnp3.ISOEHandler)
img2
img3
Potential solution and core issue
rebind opendnp3, But how?
Related
In the documentation it is indicated, that cardinality() function is deprecated and should no longer be used. However, it is still used in the libraries such as ThermoSysPro.
e.g.
if (cardinality(C) == 0) then
some code
end if;
where C is FluidInlet or FluidOutlet
Could anyone give a simple example of how it could be replaced?
The usual solution is to make the connector conditional, and if enabled you require that it is connected.
For physical connectors you can see how heatports and support is handled in:
Modelica.Electrical.Analog.Interfaces.ConditionalHeatPort
Modelica.Mechanics.Rotational.Interfaces.PartialElementaryOneFlangeAndSupport2
For control signals you can see how p_in, h_in etc are handled in
Modelica.Fluid.Sources.Boundary_pT
Modelica.Fluid.Sources.Boundary_ph
However, the connectors of ThermoSysPro belong in neither of those categories and that should ideally also be cleaned up.
The only thing I know, that could be used in this regard, is the connectorSizing annotation. It is described in the MLS chapter 18.7.
It is used a number of times in the Modelica Standard Library, e.g. in Modelica.Blocks.Math.MinMax via the parameter nu. When using it, the tool automatically sets the modifier for nu according to the number of connections to it.
parameter Integer nu(min=0) = 0 "Number of input connections"
annotation (Dialog(connectorSizing=true));
Modelica.Blocks.Interfaces.RealVectorInput u[nu];
In the example below, nu=2 is generated by Dymola automatically when creating a connection in the graphical layer. I have removed the graphical annotations, to make the code more readable.
model ExCS
Modelica.Blocks.Math.MinMax minMax(nu=2);
Modelica.Blocks.Sources.Sine sine(freqHz=6.28);
Modelica.Blocks.Sources.Constant const(k=0.5);
equation
connect(sine.y, minMax.u[1]);
connect(const.y, minMax.u[2]);
end ExCS;
The cardinality() operator is used in Modelica.Fluid.Sources.BaseClasses.PartialSource, and in a similar way in other fluid libraries (IBSPA, AixLib, Buildings, BuildingSystems and IDEAS), in the form
// Only one connection allowed to a port to avoid unwanted ideal mixing
for i in 1:nPorts loop
assert(cardinality(ports[i]) <= 1,"
each ports[i] of boundary shall at most be connected to one component.
If two or more connections are present, ideal mixing takes
place with these connections, which is usually not the intention
of the modeller. Increase nPorts to add an additional port.
");
end for;
I occasionally had models from users who somehow ended up with more than one connection to a ports[i]. How this happened was not clear, but I find the use of cardinality() useful to catch such situations, which otherwise can yield to mixing in the fluid port which the user did not intent and which are hard to detect.
I am currently refactoring a large chunk of old code and have finally dove into the HLSL section where my knowledge is minimal due to being out of practice. I've come across some documentation online that specifies which registers are to be used for which purposes:
t – for shader resource views (SRV)
s – for samplers
u – for unordered access views (UAV)
b – for constant buffer views (CBV)
This part is pretty self explanatory. If I want to create a constant buffer, I can just declare as:
cbuffer LightBuffer: register(b0) { };
cbuffer CameraBuffer: register(b1) { };
cbuffer MaterialBuffer: register(b2) { };
cbuffer ViewBuffer: register(b3) { };
However, originating from the world of MIPS Assembly I can't help but wonder if there are finite and restricted ranges on these. For example, temporary registers are restricted to a range of t0 - t7 in MIPS Assembly. In the case of HLSL I haven't been able to find any documentation surrounding this topic as everything seems to point to assembly languages and microprocessors (such as the 8051 if you'd like a random topic to read up on).
Is there a set range for the four register types in HLSL or do I just continue as much as needed in a sequential fashion and let the underlying assembly handle the messy details?
Note
I have answered this question partially, as I am unable to find a range for u currently; however, if someone has a better, more detailed answer than what I've given through testing, then feel free to post it and I will mark that as the correct answer. I will leave this question open until December 1st, 2018 to give others a chance to give a better answer for future readers.
Resource slot count (for d3d11, indeed d3d12 case expands that) are specified in Resource Limit msdn page.
The ones which are of interest for you here are :
D3D11_COMMONSHADER_INPUT_RESOURCE_REGISTER_COUNT (which is t) = 128
D3D11_COMMONSHADER_SAMPLER_SLOT_COUNT (which is s) = 16
D3D11_COMMONSHADER_CONSTANT_BUFFER_HW_SLOT_COUNT (which is b) = 15 but one is reserved to eventually store some constant data from shaders (if you have a static const large array for example)
The u case is different, as it depends on Feature Level (and tbh is a vendor/os version mess) :
D3D11_FEATURE_LEVEL_11_1 or greater, this is 64 slots
D3D11_FEATURE_LEVEL_11 : It will always be 8 (but some cards/driver eventually support 64, you need at least windows 8 for it (It might also be available in windows 7 with some platform update too). I do not recall a way to test if 64 is supported (many nvidia in their 700 range do for example).
D3D11_FEATURE_LEVEL_10_1 : either 0 or 1, there's a way to check is compute is supported
You need to perform a feature check:
D3D11_FEATURE_DATA_D3D10_X_HARDWARE_OPTIONS checkData;
d3dDevice->CheckFeatureSupport(D3D11_FEATURE_D3D10_X_HARDWARE_OPTIONS, &checkData);
BOOL computeSupport = checkData.ComputeShaders_Plus_RawAndStructuredBuffers_Via_Shader_4_x
Please note that for some OS/Driver version I had this flag returning TRUE while not supported (Intel was doing that on win7/8), so in that case the only valid solution was to try to either create a small Raw / Byte Address buffer or a Structured Buffer and check the HRESULT
As a side note feature feature level 10 or below are for for quite old configurations nowadays, so except for rare scenarios you can probably safely ignore it (I just leave it for information purpose).
Since it's usually a long wait time for these types of questions I tested the b register by attempting to create a cbuffer in register b51. This failed as I expected and luckily SharpDX spit out an exception that stated it has a maximum of 14. So for the sake of future readers I am testing all four register types and posting back the ranges I find successful.
b has a range of b0 - b13.
s has a range of s0 - s15.
t has a range of t0 - t127.
u has a range of .
At the current moment, I am unable to find a range for the u register as I have no examples of it in my code, and haven't actually ever used it. If someone comes along that does have an example usage then feel free to test it and update this post for future readers.
I did find a contradiction to my findings above in the documentation linked in my question; they have an example using a t register above the noted range in this answer:
Texture2D a[10000] : register(t0);
Texture2D b[10000] : register(t10000);
ConstantBuffer<myConstants> c[10000] : register(b0);
Note
I would like to point out that I am using the SharpDX version of the HLSL compiler and so I am unsure if these ranges vary from compiler to compiler; I heavily doubt that they do, but you can never be too sure until you try to exceed them. GLSL may be the same due to being similar to HLSL, but it could also be very different.
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+.
I've been reading through this section for a while, but I can't seem to figure it out. I'm on AMD64 ABI Draft 0.99.6, page 18, section 3.32 Parameter Passing and theres the following text:
Arguments of type __m256 are split into four eightbyte chunks. The least significant one belongs to class SSE and all the others to class SSEUP.
I'm confused because it sounds like I use three SSEUP registers and only one SSE, but that seems wasteful of the other two SSE registers associated with the SSEUP. Am I misreading it? I probably won't even use this datatype, but I've been confused on this text for quite a while. Can someone give an example of how this would work? I'm probably missing something obvious.
Page 18 just contains a list of definitions necessary for a later discussion of the algorithm used to pass the parameters of a function.
Particularly, the SSE class is always passed in a new vector register, the first available of %xmm0-%xmm7.
Note that these names refer to the lower 128-bit parts of the registers but its better to think of them in terms of variable size vector registers %v0-%v7.
The SSEUP class is passed in the next available 64-bit (eight-byte) of the last vector register used.
__m256 is then passed, in processors that support AVX, using a single %ymm register: the lower 64 bits get the SSE class - and hence a new %v0 register - while the other three 64 bits chunks get SSEUP thereby reusing the %v0 register.
Here's the relevant quote from the document:
If the class is SSE, the next available vector register is used, the registers
are taken in the order from %xmm0 to %xmm7.
If the class is SSEUP, the eightbyte is passed in the next available eightbyte
chunk of the last used vector register.
The SSEUP class was introduced earlier in the ABI and it is still present today.
You can quickly consult the Version 0.9 to see the differences: the type _m256 and _m512 were not present for example.
For compiler that doesn't support the new ABI with the _m256 type or for compilers that do support it but target processors with no AVX support, that type is usually an aggregate of two _m128 and thus by the rules described later (particularly the post-merge rules) it is passed in memory:
If the size of an object is larger than two eightbytes, or in C++, is a nonPOD structure or union type, or contains unaligned fields, it has class
MEMORY.
For compilers using the old ABI
If the size of the aggregate exceeds two eightbytes and the first eightbyte
isn’t SSE or any other eightbyte isn’t SSEUP, the whole argument
is passed in memory.
For compilers using the new ABI
The standard is admittedly confusing mostly due to the need to address backward compatibility, the SSE and SSEUP classifications are handy classifications in an architecture where the vector registers keep widening and broad range of different sizes are already present out there.
Simple question:
I've added some scales (sliders) to my window, and I want to call a method when you move the scale.
What is the signal name that I use for gtk_signal_connect?
ie I should be able to write something like:
gtk_signal_connect(GTK_OBJECT(my_scale), "scale_moved", (GtkSignalFunc)my_event, data);
or am I missing something here?
And more importantly - how do I find out in the future what the signal names are? for example - I googled 'gtk_signal_connect' but I didn't find a big list of different signals.
Similarly, I didn't find details about related signals in the GtkScale documentation. (Well, in this page, there is a single signal detail, but it relates to changing the displayed value format).
GtkScale inherits from GtkRange, and signals are inherited in GTK+. Therefore, you can connect to the value-changed signal exposed by GtkRange.
You're on the right track to find the signals exposed by a given GTK+ widget: besides the source code itself, the documentation is indeed the canonical resource, but you should also take the base classes into account in your search.