Micromaster 440. Ways to limit output frequency on the run? - plc

I need to control a conveyor (driven by Micromaster 440) from a PC program using SFC14/15.
The scheme will be: Supervisors PC ->(ethernet)-> S7-1200 ->(profibus)-> Micromaster 440.
At the moment, Micromaster's output frequency is controlled via a potentiometer (analog inputs) by the "field" operator. The problem is that sometimes the operator increases the conveyor speed in order to do his job faster and this affects the production negatively. The "supervisor" wants to be able to limit output frequency using the PC program.
Of course I've seen the list of MM440 parameters and I know about P1082, but I've discovered that, unfortunately, MM440 should be stopped before the new value of P1082 takes effect. In my case it's preferable to be able to change the value on the run.
Fortunately, it seems that P0757 - P0760 - (input scaling) can be changed on the run, but this parameter has sign "first confirm", which means that
the “P” button on the operator panel (BOP or AOP) must be pressed before the
changes take effect.
But the MM440 has only one slot for the Profibus/BOP/AOP panel and I'll be using Profibus. So, in this case, what will be the behavior of mm440 like? I want to believe that, perhaps, this condition is not obligatory when using profibus panel...

I would opt for a solution where the operator no longer operates the belt speed directly but tells the S7-1200 PLC a what speed he would like the belt to run (either by using 2 +/- buttons or a pot-meter). The PLC can then control the speed of the belt (either by analog output or 2 digital (+/-) outputs).
As an added bonus you can stop the belt when it is accidentally left on and things like that...

Related

If the PC register is simultaneously read and written, does its read data contain the previous data or the newly-written data?

If the PC register is simultaneously read and written, does its read data contain the previous data or the newly-written data? Based on my understanding of sequential circuits, the effect of the write command does not instantly take effect in the PC register due to propagation delay so, at the rising edge of the clock, the read command will get the old value. But corollary to my question is if this is the case, shouldn't the read command would also have a delay in some sense and could possibly read the newly-written data?
A program counter is normally special enough that it's not part of a register file with other registers. You don't have a "read command", its output is just always wired up to other parts that read it when appropriate. (i.e. when its output is stable and has the value you want). e.g. see various block diagrams of MIPS pipelines, or non-pipelined single-cycle or multi-cycle designs.
You'd normally build such a physical register out of edge-triggered flip-flops, I think. (https://en.wikipedia.org/wiki/Flip-flop_(electronics)). Note that a D flip-flop does latch the previous input as the current output on a clock edge, and then the input is allowed to change after that.
There's a timing window before the clock edge where the input has to remain stable, it can start to change a couple gate delays after. Note the example of a shift register built by chaining D flip-flops all with the same clock signal.
If you have a problem arranging to capture a value before it starts changing, you could design in some intentional clock skew so the flip-flop reliably latches its input before you trigger the thing providing the input to change it. (But normally whatever you're triggering will itself have at least a couple gate delays before its output actually changes, hence the shift-register made of chained D flip-flops.)
That wiki article also mentions the master-slave edge-triggered D Flip-Flop that chains 2 gated (not clocked) D latches with an inverted clock, so capturing the input happens on the opposite clock edge from updating the output with the previously-captured data.
By comparison and for example, in register files for general-purpose registers in classic RISC pipelines like MIPS, IIRC it's common to build them so write happens in the first half-cycle and read happens in the second half-cycle of the ID stage. (So write-back can "forward" to decode/fetch through the register file, keeping the window of bypass-forwarding or hazards shorter than if you did it in the other order.)
This means the write data has a chance to stabilize before you need to read it.
Overall, it depends how you design it!
If you want the same clock edge to update a register with inputs while also latching the old value to the output, you a master-slave flip-flop will do that (capture the old input into internal state, and latch the old internal state onto the outputs).
Or you could design it so the input is captured on the clock edge, and propagates to the output after a few gate delays and stays latched there for the rest of this clock cycle (or half cycle). That would be a single D flip-flop (per bit).

Matlab Simulink: while loop with subtraction

I am hoping somebody here will be able to help me out with my small issue with one of the Simulink/Matlab code. It is quite similar to the problem that I’ve discussed earlier, but a little bit more complicated and now it is more a Simulink issue, rather than a Matlab one.
So I have a turbine which speed is controlled by the gate’s opening, hence the control voltage. By controlling the gate opening I am accelerating the turbine and at some point in time, I need to introduce a saturation effect (since I am testing the code now, it will be done an external signal). This effect won’t change the control voltage, but it affects other components of the system, hence at the same control voltage, the turbine’s speed will go up. But at the same time, I need to keep the speed at the same value as it was before the saturation effect (let’s say it was 320 rpm). To do so I need to decrease the control voltage and should keep doing it until I reach the speed as it was before. There is no need to do it instantly (this approach will be later introduced in hardware), but it will be a nice thing to check the algorithm in these synthetic tests.
In terms of the model, I was planning to use a while loop with the speed requirement “if speed > 320” again, now just to simplify things. To decrease the control voltage I was planning to subtract from the original 50 (% opening) - 0.25 (u2) at first and after that increasing this value by 0.25 until I decrease the speed below 320. I can’t know the exact opening when this requirement will be satisfied, hence I need some kind of algorithm to “track” this voltage.
So it should be something like this:
u2 = 0;
While speed > 320
u2 = u2+0.25
End
u2 is initially zero since we have a predefined initial control voltage. And obviously, when we reach the motor’s speed below 320, I need to keep the latest value of the u2 (and control voltage).
Overall, it is a small code and should be done in Simulink (don’t want to introduce any other Fcn function into the model). I’ve never used while and if blocks in Simulink, but so far I came up with this system. It’s a simplified version of my model, but the control principle is the same.
We are getting the motor speed of 350, compared with 320 (the speed before “saturation), and if our speed after saturation is higher, we need to reduce the control voltage. To trigger the while loop block I’ve decided to use a simple switch. The while block meanwhile is:
Definitely not the best implementation but I was trying a lot of different combinations and without any real success. I am always getting the same error:
Was trying to use a step signal instead of the constant “7” – to model acceleration of the motor, and was getting the same error at the moment of acceleration above 320 threshold. So looks like the approach is almost right but mathematically it fails to find the most suitable solution. I’ve tried to implement a transport delay in the memory part of the while subsystem but was getting errors during compilation all the time.
Are there any obvious (and not so) mistakes? Or maybe from the beginning, I should have chosen another approach… I really hope that somebody will be able to help. Thank you in advance and have a great day.
I do not think that you have used While block correctly.
This is what I have done, I used a "Matlab function" block instead of "While" block as follows,
The function in Matlab function is
function u2=fcn(speed,u2d)
if speed>320
u2=u2d+0.25;
else
u2=u2d;
end
And the results I have got, Scope 1
Scope
Edit
As you prefer a function free model, the following may do the same.

How to make simulated electric components behave nicely?

I'm making a simple electric circuit simulator. It will (at least initially) only feature batteries, wires and resistors in series and parallel. However, I'm at a loss how best to simulate said circuit in a good way.
Specifically, I will have batteries and resistors with two contact points each, and wires that go between two contact points. I assume that each component will have a field for its resistance, the current through it and the voltage across it (current and voltage will, of course, be signed). Each component is given a resistance, and the batteries are given a voltage. The goal of the simulation is to assign correct values to all the other fields in real time as the player connects and disconnects components and wires.
These are the requirements:
It must be correct, including Ohm's and Kirchhoff's laws (I'm modeling real world circuits, and there is little point if the model does something completely different)
It must be numerically stable (we can't have uncontrolled oscillations or something just because two neighbouring resistors can't make up their minds together)
It should stabilize relatively quickly for, let's say, fewer than 30 components (having to wait a few seconds before the values are correct doesn't really satisfy "real time", but I really don't plan on using it for more than 10 or maybe 20 components)
The optimal formulation for me (how I envision this in my head) would be if I could assign a script to each component that took care of that component only, possibly by communicating field values with neighbouring components, and each component script works in parallel and adjusts as is needed
I only see problems here and no solutions. The biggest problem, I think, is Kirchhoff's voltage law (going around any sub-circuit, the voltage across all components, including signs, add up to 0), because that's a global law (it says somehting about a whole circuit and not just a single component / connection point). There is a mathematical reformulation saying that there exists a potential function on the points in the circuit (for instance, the voltage measured against the + pole of the battery), which is a bit more local, but I still don't see how to let a component know how much the voltage / potential drops across it.
Kirchhoff's current law (the net current flow into an intersection is 0) might also be trouble. It seems to force me to make intersections into separate objects to enforce it. I originally thought that I could just let each component have two lists (a left list and a right list) containing every other component that is connected to it at that point, but that might not make KCL easily enforcable.
I know there are circuit simulators out there, and they must have solved this exact problem somehow. I just can't find an explanation because if I try googling it, I only find the already made simulators and no explanations anywhere.

High latency when transmitting with HackRF One from GNU Radio

So I reverse-engineered an RC toy wireless protocol, and written a flow graph in GNU Radio Companion for reproducing the toy's commands.
The sink block is osmocom sink, and transmitting device is HackRF One.
The problem I encountered is severe lag between pressing button and toy reacting, which is about 1-2 seconds.
Quickly pressing, for example, "forward" button twice will result in toy jerking forward twice in quick succession as well, about a second after pressing. So it's not like the flow graph itself is slow. The CPU usage is also fairly low. This looks like some buffering issue.
I'm pretty sure that the flow graph itself reacts to button presses instantly, as debugging prints appear the same time as button is pressed/depressed, and square waves appear in the GUI scope sink instantly, as well.
I tried to lower number of HackRF buffers to one (by settings device arguments to hackrf,buffers=1), but it didn't help.
I set "Max Number of Outputs" to 10 for flow graph as well, and it also didn't make a difference (I tried some other values, too). Given that signal appears in the GUI scope much sooner than after 1 second, it shouldn't have worked anyway.
How can I reduce the latency then?
EDIT: I followed #Manos's suggestion and tried adjusting sample rate.
Adding a rational resampler block with interpolation of 8 (and adjusting sink sample rate accordingly) AND setting hackrf,buffers=1 makes latency almost non-existent.
However, reducing output sample rate of my custom block to 500k and having 16x interpolation still causes noticeable lag, maybe 400-500ms (still not as dramatic as when it's 1M at both source and sink). I'm not sure how to fix it. Unfortunately, running my custom block at 1M consumes 100% CPU and causes occasional underflows.

Running a filter at a high speed

I'm writing a signal processing software in CVI.
I've got a signal, transmitted to the computer via USB at a very high speed (~50K).
I want to filter it in RT.
In order to do it I created a filter in Simulink and turned it into a C code, which I run in CVI using:
FuncName_initialize()
FuncName.in
FuncName_step()
FuncName.Out
The thing is that after a while (about 5-7 min) the filter works wrongly... Meaning showing inaccurate results and artifacts. I believe this is a result of using it too fast (because I used it before at lower speeds and this was fine).
Any suggestions on what might be the problem? How can I implement a RT filter in CVI directly (meaning a one that get one point at the input and gets one point in the output while maintaining some window).
I know that the data transmitted just fine at this speed since recording the signal works OK, and showing the raw data on screen works OK as well.
Thank you