I'm using Wago PLC - PFC200 - for home automation. I already did most of the things like lights or blinds automation. Recently I decided to do some refactoring and I started to think that such PLC is not a PC with a garbage collector and it might be beneficial instead of passing POU's in the table pass pointers to those POU's.
I started with something like this:
Declaration:
VAR
Lighs: ARRAY [1..siTotalLightsCount] OF Relay;
END_VAR
where Relay is my POU (program organization unit - like a class).
Initialization:
Lighs[1] := MainLightRelay;
Lighs[2] := WindowLightRelay;
Lighs[3] := IslandLightRelay;
Usage in POU method:
FOR siCurrent := 1 TO siTotalLightsCount DO
Lighs[siCurrent].xCentralOff := xCentralOffSignal;
END_FOR
But I might be beneficial to save some memory for variables and go with such an approach:
Declaration:
VAR
Lighs: ARRAY [1..siTotalLightsCount] OF POINTER TO Relay;
END_VAR
Initialization:
Lighs[1] := ADR(MainLightRelay);
Lighs[2] := ADR(WindowLightRelay);
Lighs[3] := ADR(IslandLightRelay);
Usage in POU method:
FOR siCurrent := 1 TO siTotalLightsCount DO
Lighs[siCurrent]^.xCentralOff := xCentralOffSignal;
END_FOR
Is that make sense? I had like 15 rooms in my home, most of the rooms has more than one light (so more Relay objects). It's not much, however, PLC is not PC, there are some memory constraints.
Related
I am studying the design of riscv-Boom. It is designed with chisel. When I read its source code, I always cannot understand when the signals in these circuits will be obtained. Normal programs are executed one by one. But hardware languages like chisel are not.
https://github.com/riscv-boom/riscv-boom/blob/master/src/main/scala/exu/issue-units/issue-slot.scala
For example, the link above is the source code of Issue-slot in Boom.
103: val next_uop = Mux(io.in_uop.valid, io.in_uop.bits, slot_uop)
113: state := io.in_uop.bits.iw_state
126: next_state := state
127: next_uopc := slot_uop.uopc
128: next_lrs1_rtype := slot_uop.lrs1_rtype
129: next_lrs2_rtype := slot_uop.lrs2_rtype
155 slot_uop := io.in_uop.bits
208: for loop
This is some code in the IssueSlot class in the link above. For the chisel hardware language, these := should mean that they are connected together by wires. So do these signals change at the same time? For example, when io.in_uop.valid is true, does the above code assign values at the same time?
For example, the current uop is fmul, and in_uop= is fadd. When io.in_uop.valid, the above code will be executed at the same time. But there is a problem.
origin
uop = fmux
when io.in_uop.valid
103: val next_uop = io.in_uop.bits (fadd uop)
113: state := io.in_uop.bits.iw_state (fadd state)
126: next_state := state (fmux state)
127: next_uopc := slot_uop.uopc (fmux uopc)
128: next_lrs1_rtype := slot_uop.lrs1_rtype (fmux lrs1_rtype )
129: next_lrs2_rtype := slot_uop.lrs2_rtype (fmux lrs2_rtype )
155 slot_uop := io.in_uop.bits (faddlrs2_rtype )
208: for loop
When io.in_uop.valid is true, the transmit slot at this time will be input fadd information. At the same time, the original fmul information will still be output to next-related signals. This should be unreasonable. Where does the problem occur?
For the for loop of line 207. I still find it difficult to understand. Will the for loop be executed in one beat? For example, if I use a for loop to traverse a queue, when did the for loop finish?
If anyone is willing to answer me, I would be extremely grateful!
first
The a := b expression mean that b is connected to a yes. b is the source and a the sink.
If a new connection to a is done after in the code, it will be replaced.
In the following code, a is connected to c:
a := b
a := c
This writing could be strange but it's usefull to set a default value in conditionnal branch.
For example :
a := b
when(z === true.B){
a := c
}
By default, a will be connected to b except when z is true.
second
Do not forget that Chisel is an HDL generator. It generate hardware code, some keywords are pure Scala like if, for, ... and other are hardware chisel keyword like when, Mux, ...
Then the for loop in line 208 is executed at the code generation stage. And it will generate some hardware chisel when mux code.
I'd highly recommend you spend some time with the Chisel Bootcamp. It can really help you grasp the generator aspects of chisel.
I am trying to have a loop where it will start at 100 and drop until it hits to a point where the while condition no longer holds true.
I started with
While Solar_Power_House_W_Solar_PER <= OneHundred AND BatChargePercent < OneHundred DO
State_Dis_Charge := false
FOR PLC_SetLoopChargeValue:= 100 TO 0 By -1 DO
ConvertoReal := INT_TO_LREAL(PLC_SetLoopChargeValue);
Divide := ConvertoReal DIV(100);
PLC_SetCharge := Divide;
PLC_Charge := 1500 * PLC_SetCharge;
RB_Charge := PLC_Charge;
Visual_RBPower := 1500 * PLC_SetCharge; (*Charge *)
END_FOR;
The problem I believe I have with this is that it cycles too fast so the condition never gets out of the while loop because it takes a while for the system to update so I thought of adding a delay portion:
While Solar_Power_House_W_Solar_PER <= OneHundred AND BatChargePercent < OneHundred DO
State_Dis_Charge := false;
wait(IN:=not wait.Q , PT:=T#50ms);
if Wait.Q Then
FOR PLC_SetLoopChargeValue:= 100 TO 0 By -1 DO
ConvertoReal := INT_TO_LREAL(PLC_SetLoopChargeValue);
Divide := ConvertoReal DIV(100);
PLC_SetCharge := Divide;
PLC_Charge := 1500 * PLC_SetCharge;
RB_Charge := PLC_Charge;
Visual_RBPower := 1500 * PLC_SetCharge; (*Charge *)
END_FOR;
END_IF;
END_WHILE;
How I think it should work is every 50ms 1 for loop should run. Currently nothing happens every 50ms.
You have to consider that WHILE and FOR are executed synchronously. It means blocking. It means that interpreter do not execute next line, until previous line is finished.
This means that "running to fast" cannot apply here. It does not matter how fast it runs, the execution of the lines will be always in order.
The only thing I would change and loop not from 100 to 0 but vice versa from 0 to 100, because I am not sure this backward will work fine. And then all you have to change:
ConvertoReal := INT_TO_LREAL(100 - PLC_SetLoopChargeValue);
You do now show all code it is VERY HARD to judge but if FOR loom is complete it totally make no sense. You calculate some variables but you do not use them there. You know that you cannot use them outside of your FOR loop, right? Because outside of your FOR loop those variable will be always same value of last loop.
In your second example your FOR loop, although it might work, you should not use timer to run the loop inside the loop. Because loops are synchronous and times async.
As I understand you task you do not need WHILE at all. With this approach your program execution of other parts will be blocked until 100%. That might take a while as I can see. So you have to use IF.
IF Solar_Power_House_W_Solar_PER <= OneHundred AND BatChargePercent < OneHundred DO
// ....
END_IF;
The difference is significant. With WHILE it will block your program till WHILE finish and other parts will not be executed for this long, in the same PLC cycle FOR might be executed so many times.
With IF if will run FOR one time per one PLC cycle and actualy doe snot change your logic.
If you would share your full code or at least parts where variables you have here are used so that the whole picture is visible, you might get a better help. Edit your post and I'll edit my comment.
With this answer im only adressing your issue with the for loop not being executed every 50ms.
The other answers why the while loop cant be exited are correct unless the variables Solar_Power_House_W_Solar_PER and BatChargePercent aren't changed in a parrellel thread.
I suggest wait is a TON function block. Please mind that names of FBs are case sensitive: wait.Q is possibly unequal Wait.Q. I think that is the main reason your for loop is not executed, because you check the output of another FB. Maybe check your declaration list for doubles with higher or lower cases.
Another possibility is, that your condition for the while loop isn't met at all and you didn't notice. In this case the for loop wouldn't be executed too of course.
I developed a procedure that receives a TStream; but the basic type, to allow the sending of all the types of stream heirs.
This procedure is intended to create one thread to each core, or multiple threads. Each thread will perform detailed analysis of stream data (read-only), and as Pascal classes are assigned by reference, and never by value, there will be a collision of threads, since the reading position is intercalará.
To fix this, I want the procedure do all the work to double the last TStream in memory, allocating it a new variable. This way I can duplicate the TStream in sufficient numbers so that each thread has a unique TStream. After the end of the very thread library memory.
Note: the procedure is within a DLL, the thread works.
Note 2: The goal is that the procedure to do all the necessary service, ie without the intervention of code that calls; You could easily pass an Array of TStream, rather than just a TStream. But I do not want it! The aim is that the service is provided entirely by the procedure.
Do you have any idea how to do this?
Thank you.
Addition:
I had a low-level idea, but my knowledge in Pascal is limited.
Identify the object's address in memory, and its size.
create a new address in memory with the same size as the original object.
copy the entire contents (raw) object to this new address.
I create a pointer to TStream that point to this new address in memory.
This would work, or is stupid?? If yes, how to operate? Example Please!
2º Addition:
Just as an example, suppose the program perform brute force attacks on encrypted streams (just an example, because it is not applicable):
Scene: A 30GB file in a CPU with 8 cores:
1º - TMemoryStream:
Create 8 TMemoryStream and copy the entire contents of the file for each of TMemoryStreams. This will result in 240GB RAM in use simultaneously. I consider this broken idea. In addition it would increase the processing time to the point of fastest not use multithreading. I would have to read the entire file into memory, and then loaded, begin to analyze it. Broke!
* A bad alternative to TMemoryStream is to copy the file slowly to TMemoryStream in lots of 100MB / core (800MB), not to occupy the memory. So each thread looks only 100MB, frees the memory until you complete the entire file. But the problem is that it would require Synchronize() function in DLL, which we know does not work out as I open question in Synchronize () DLL freezes without errors and crashes
2º - TFileStream:
This is worse in my opinion. See, I get a TStream, create 8 TFileStream and copy all the 30GB for each TFileStream. That sucks because occupy 240GB on disk, which is a high value, even to HDD. The read and write time (copy) in HD will make the implementation of multithreaded turns out to be more time consuming than a single thread. Broke!
Conclusion: The two approaches above require use synchronize() to queue each thread to read the file. Therefore, the threads are not operating simultaneously, even on a multicore CPU. I know that even if he could simultaneous access to the file (directly creating several TFileStream), the operating system still enfileiraria threads to read the file one at a time, because the HDD is not truly thread-safe, he can not read two data at the same time . This is a physical limitation of the HDD! However, the queuing management of OS is much more effective and decrease the latent bottleneck efficiently, unlike if I implement manually synchronize(). This justifies my idea to clone TStream, would leave with S.O. all the working to manage file access queue; without any intervention - and I know he will do it better than me.
Example
In the above example, I want 8 Threads analyze differently and simultaneously the same Stream, knowing that the threads do not know what kind of Stream provided, it can be a file Stream, a stream from the Internet, or even a small TStringStream . The main program will create only one Strean, and will with configuration parameters. A simple example:
TModeForceBrute = (M1, M2, M3, M4, M5...)
TModesFB = set of TModeForceBrute;
TService = record
stream: TStream;
modes: array of TModesFB;
end;
For example, it should be possible to analyze only the Stream M1, M2 only, or both [M1, M2]. The TModesFB composition changes the way the stream is analyzed.
Each item in the array "modes", which functions as a task list, will be processed by a different thread. An example of a task list (JSON representation):
{
Stream: MyTstream,
modes: [
[M1, m5],
[M1],
[M5, m2],
[M5, m2, m4, m3],
[M1, m1, m3]
]
}
Note: In analyzer [m1] + [m2] <> [m1, m2].
In Program:
function analysis(Task: TService; maxCores: integer): TMyResultType; external 'mydll.dll';
In DLL:
// Basic, simple and fasted Exemple! May contain syntax errors or logical.
function analysis(Task: TService; maxCores: integer): TMyResultType;
var
i, processors : integer;
begin
processors := getCPUCount();
if (maxCores < processors) and (maxCores > 0) then
processors := maxCores;
setlength (globalThreads, processors);
for i := 0 to processors - 1 do
// It is obvious that the counter modes in the original is not the same counter processors.
if i < length(Task.modes) then begin
globalThreads[i] := TAnalusysThread.create(true, Task.stream, Task.modes[i])
globalThreads[i].start();
end;
[...]
end;
Note: With a single thread the program works beautifully, with no known errors.
I want each thread to take care of a type of analysis, and I can not use Synchronize() in DLL. Understand? There is adequate and clean solution?
Cloning a stream is code like this:
streamdest:=TMemoryStream.create;
streamsrc.position:=0;
streamdest.copyfrom(streamdest);
streamsrc.position:=0;
streamdest.position:=0;
However doing things over DLL borders is hard, since the DLL has an own copy of libraries and library state. This is currently not recommended.
I'm answering my question, because I figured that no one had a really good solution. Perhaps because there is none!
So I adapted the idea of Marco van de Voort and Ken White, for a solution that works using TMemoryStream with partial load in memory batch 50MB, using TRTLCriticalSection for synchronization.
The solution also contains the same drawbacks mentioned in addition 2; are they:
Queuing access to HDD is the responsibility of my program and not of the operating system;
A single thread carries twice the same data in memory.
Depending on the processor speed, it may be that the thread analyze well the fast 50MB of memory; On the other hand, to load memory can be very slow. That would make the use of multiple threads are run sequentially, losing the advantage of using multithreaded, because every thread are congested access to the file, running sequentially as if they were a single thread.
So I consider this solution a dirty solution. But for now it works!
Below I give a simple example. This means that this adaptation may contain obvious errors of logic and / or syntax. But it is enough to demonstrate.
Using the same example of the issue, instead of passing a current to the "analysis" is passed a pointer to the process. This procedure is responsible for making the reading of the stream batch 50MB in sync.
Both DLL and Program:
TLotLoadStream = function (var toStm: TMemoryStream; lot, id: integer): int64 of object;
TModeForceBrute = (M1, M2, M3, M4, M5...)
TModesFB = set of TModeForceBrute;
TaskTService = record
reader: TLotLoadStream; {changes here <<<<<<< }
modes: array of TModesFB;
end;
In Program:
type
{ another code here }
TForm1 = class(TForm)
{ another code here }
CS : TRTLCriticalSection;
stream: TFileStream;
function MyReader(var toStm: TMemoryStream; lot: integer): int64 of object;
{ another code here }
end;
function analysis(Task: TService; maxCores: integer): TMyResultType; external 'mydll.dll';
{ another code here }
implementation
{ another code here }
function TForm1.MyReader(var toStm: TMemoryStream; lot: integer): int64 of object;
const
lotSize = (1024*1024) * 50; // 50MB
var
ler: int64;
begin
result := -1;
{
MUST BE PERFORMED PREVIOUSLY - FOR EXAMPLE IN TForm1.create()
InitCriticalSection (self.CriticalSection);
}
toStm.Clear;
ler := 0;
{ ENTERING IN CRITICAL SESSION }
EnterCriticalSection(self.CS);
{ POSITIONING IN LOT OF BEGIN}
self.streamSeek(lot * lotSize, soBeginning);
if (lot = 0) and (lotSize >= self.stream.size) then
ler := self.stream.size
else
if self.stream.Size >= (lotSize + (lot * lotSize)) THEN
ler := lotSize
else
ler := (self.stream.Size) - self.stream.Position; // stream inicia em 0?
{ COPYNG }
if (ler > 0) then
toStm.CopyFrom(self.stream, ler);
{ LEAVING THE CRITICAL SECTION }
LeaveCriticalSection(self.CS);
result := ler;
end;
In DLL:
{ another code here }
// Basic, simple and fasted Exemple! May contain syntax errors or logical.
function analysis(Task: TService; maxCores: integer): TMyResultType;
var
i, processors : integer;
begin
processors := getCPUCount();
if (maxCores < processors) and (maxCores > 0) then
processors := maxCores;
setlength (globalThreads, processors);
for i := 0 to processors - 1 do
// It is obvious that the counter modes in the original is not the same counter processors.
if i < length(Task.modes) then begin
globalThreads[i] := TAnalusysThread.create(true, Task.reader, Task.modes[i])
globalThreads[i].start();
end;
{ another code here }
end;
In DLL Thread Class:
type
{ another code here }
MyThreadAnalysis = class(TThread)
{ another code here }
reader: TLotLoadStream;
procedure Execute;
{ another code here }
end;
{ another code here }
implementation
{ another code here }
procedure MyThreadAnalysis.Execute;
var
Stream: TMemoryStream;
lot: integer;
{My analyzer already all written using buff, the job of rewriting it is too large, then it is so, two readings, two loads in memory, as I already mentioned in the question!}
buf: array[1..$F000] of byte; // 60K
begin
lot := 0;
Stream := TMemoryStream.Create;
self.reader(stream, lot);
while (assigned(Stream)) and (Stream <> nil) and (Stream.Size > 0) then begin
Stream.Seek(0, soBeginning);
{ 2º loading to memory buf }
while (Stream.Position < Stream.Size) do begin
n := Stream.read(buf, sizeof(buf));
{ MY CODE HERE }
end;
inc(lot);
self.reader(stream, lot, integer(Pchar(name)));
end;
end;
So as seen this is a stopgap solution. I still hope to find a clean solution that allows me to double the flow controller in such a way that access to data is the operating system's responsibility and not my program.
I am automating an open source program written in Delphi. From the main form, I am performing the following loop:
for i := 0 to analysisNames.Count - 1 do begin
currentAnalysisName := analysisNames[i];
analysisID := DatabaseModule.GetAnalysisIDForName(analysisNames[i]);
frmIIGraph.autoMode := true;
frmIIGraph.ShowModal();
end;
As you can see, it opens a form called frmIIGraph. Inside that form, I must open another form, which I do with the following code:
procedure TfrmIIGraph.FormActivate(Sender: TObject);
begin
if autoMode then begin
events := DatabaseModule.GetEvents(analysisID);
frmEventEdit.autoMode := true;
frmEventEdit.OpenDialog(events,0,analysisID);
frmEventEdit.ShowModal();
//frmEventEdit.Close;
SetFocus;
ModalResult := mrOK;
PostMessage(Self.Handle,wm_close,0,0);
end;
end;
The form opened from the above method is called frmEventEdit. Within that form I am running this code:
procedure TfrmEventEdit.FormActivate(Sender: TObject);
begin
if autoMode then begin
btnRTK_CalcClick(nil);
ModalResult := mrOK;
PostMessage(Self.Handle,wm_close,0,0);
end;
end;
The problem is that the PostMessage(Self.Handle,wm_close,0,0); in the latter code works fine and closes the form, resuming the code on the frmIIgraph at SetFocus;. However, the PostMessage(Self.Handle,wm_close,0,0); in the IIGraph form code, does not close the graph form, so that execution can resume on the main form, for the next iteration of the loop. You have to manually close the graph for it to proceed.
Any help is appreciated.
Your fundamental problem is that you have coded all your business logic in GUI code. So you are not able to execute the code that you want to execute without the convoluted code seen in the question.
If you want to solve your real problem you will deal with the root cause of your woes. You will separate the business logic and the GUI code. You will arrange for your business logic to be able to be executed in the absence of GUI.
If you don't want to solve your real problem, and wish to continue with this madness, you need to post a WM_CLOSE message to frmIIGraph.Handle in the OnDeactivate event handler for TfrmEventEdit. Presumably the one you post in TfrmIIGraph.FormActivate is getting consumed by the sub-form's message loop, or perhaps some call to ProcessMessages. But I cannot endorse this as a sane way to proceed.
Currently in my program I have a Startup form, and a Main form. The startup form shows for a second or two.
Right now, I have the following code within a timer:
frmStartup.Destroy;
frmMain := TfrmMain.Create(Self);
frmMain.Show;
Right now, I'm not sure if this is the correct way to do it.. It works, but when calling application.Terminate();
I receive an access violation message, leading my to believe that I have done something wrong in the destruction of the startup form..
If anyone could show the the correct procedure for doing what I want (non-modally) It would be greatly appreciated.
Thanks in advance,
EDIT:
Thanks for all the feedback, I fixed my access violations by simply adding the code:
Action := caFree;
Into the frmStartup.formClose method.
Don't create the frmStartup using Application.CreateForm. The first form created there becomes your application's main form, and if that's frmStartup you're destroying it outside Application knowledge.
Instead, use a normal Form.Create in your project source (.dpr) file:
var
frmStartup: TfrmStartup;
begin
Application.Initialize;
Application.MainFormOnTaskBar := True;
frmStartup := TfrmStartup.Create(nil); // No owner assigned here!
frmStartup.Show;
frmStartup.Update;
Application.CreateForm(TfrmMain, frmMain); // Let Application have this for main form
// Delay here if needed
frmfrmStartup.Free;
Application.Run;
end.
You may want to have your Splash Screen showing up as early as possible, so ideally it should be done during the initialization phase, then it should disappear only when the MainForm is ready to take over.
That's exactly what we do in our application where we reuse the About dialog as a splash screen then release it when the MainForm steals the focus.
In the dpr, as high as possible in the uses clause after the needed VCL/RTL units:
f_adtDlgAbout in 'f_adtDlgAbout.pas' {frmDlgAbout}, // ASAP to be used as a Splash screen
The About unit (FYI, FormStyle is fsStayOnTop and Position is poScreenCenter):
unit f_adtDlgAbout;
[...]
type
TfrmDlgAbout = class(TForm)
[...]
procedure TfrmDlgAbout.SplashFormDeactivate(Sender: TObject);
begin
Release;
end;
initialization
// Use it as a Splash screen
with TfrmDlgAbout.Create(nil) do begin
AlphaBlend := True;
AlphaBlendValue := 208;
BorderStyle := bsNone;
btnOK.Visible := False;
OnDeactivate := SplashFormDeactivate;
Show;
Update;
end;
end.
TFrmMain.Create(Self)??? What is "Self"? Are you doing that from inside frmStartup? If so, don't. Use TFrmMain.Create(NIL).
Use frmStartup.Release to release frmStartup, if all of the code you sent is inside a method of frmStartup, you need to put that line at the bottom of the method.
Set frmMain as Main Form
On frmMain.FormCreate
frmStartup := TfrmStartup.Create(nil);
try
frmStartup.ShowModal;
finally
frmStartup.Free;
end;