I need a simple and cheap "PLC" or another device to execute very simple task based on hardware input and outputs.
The goal is to simulate "switchgear" in a high voltage power substation, breakers and disconnectors.
Basicly it gives feedback of the device when in "open or closed state" based on "open and close commands" given
There are 7 devices in a bay, so there should be:
14 inputs for commands (7 open and 7 close commands)
14 outputs for states (7 open and 7 closed states)
The hardware input and outputs should handle 220V DC.
A small monitor or LEDs to show the states would be preferable.
I know this can be done with "simple relay technique", but the relays I can find capable for this are pretty expensive and pretty huge.
I also know it can be done by programming, and here is the basic idea of the code:
Variable_A = 0 'There should be 7 variables, so a copy of the entire code with variables A to G
If Hardware-input 1 'open command
Set Var_A: 0
delay 2s 'delay to
Set Var_A: 1
If Hardware-input 2 'close command
Set Var_A: 0
delay 2s
Set Var_A: 2
Case
Var_A = 0 'between state
Hardware-output1 = 0
Hardware-output2 = 0
Var_A = 1 'open state
Hardware-output1 = 0
Hardware-output2 = 1
Var_A = 2 'closed state
Hardware-output1 = 1
Hardware-output2 = 0
Var_A = 3 'illigal state
Hardware-output1 = 1
Hardware-output2 = 1
What I thought of is a Siemens DIN-rail PLC or a raspberry PI with external inputs/outputs.
So Im asking if anyone can recommend a good solution to this?
I was suggested Arduino and this seems like a perfect solution.
I believe you should ask this question in the Electrical Engineering Stack Exchange.
220VDC would be very unusual for a PLC.A common PLC with 24VDC Input and output will be a cheaper option.To use conventional 24VDC PLC I/O, you could place solid state relays or opto-couplers between the field devices and the PLC.
Related
I'm working around a connection between a PLC device and my companies PC. The PLC is the known Siemens S7-200 and I'm using vb.NET. Probably I should use another language but vb.NET is the one I'm more comfortable with. To do so, I'm also using a PPI protocol through COM1 and LibNoDave library to establish the connection.
The program I'm testing has to have Input 0.0 On, so I attached a switch to make it happen. Also I made a vb console to read (and write) the state of the Inputs and Outputs (as the LED physical indicators on the device) and also the state of the Bit memories:
The console reader (LEITOR section - sorry) is working like I intended and all the Q's, I's and M's are correctly lighting up if it is the case.
The problem is, to run the PLC program, I also have to lit up Q 1.1.
The Ladder Network that describes this has the following logical map:
I know I have to use the code:
Public FDS As libnodave.daveOSserialType 'Serial type
Public DI As libnodave.daveInterface 'Interface
Public DC As libnodave.daveConnection 'Connection
Public lPPI As Integer = 0 'Local
Public pPPI As Integer = 2 'PLC
Public RES As Integer = 0 'Response
Public REP As Integer = 0 'Response
Public buf(100) As Byte
Sub Code()
FDS.rfd = libnodave.setPort("COM1", "9600", AscW("E"))
DI = New libnodave.daveInterface(FDS, "IF1", lPPI, libnodave.daveProtoPPI, libnodave.daveSpeed93k)
DI.setTimeout(1000000)
DC = New libnodave.daveConnection(DI, pPPI, 0, 0)
RES = DC.connectPLC
'Write on PLC:
RES = DC.writeBytes(...
End sub
The code is working fine with no errors and an establish connection (until the last RESponse).
Here's the problem:
I can lit up the Output 1.1 (on the device and on the console) by doing the following:
RES = DC.writeBytes(libnodave.daveDB, 1, 1500, 16, buf)
where
buf = BitConverter.GetBytes(libnodave.daveSwapIed_16(30))
by repeating these two steps five more times (another time with 30 again, two more times with 50 and, finally, another two times with 50).
I'm pretty sure I'm doing something wrong, but there's not a lot of these commands description available online for a guy like me (who's just got started).
Can anyone explain what's going on? And also, How can I lit Q 1.1 with just one step?
Do you know how to set up the Spreading Factor to 12 in a Mbed-OS LoRaWAN protocol APIs to connect to a LoRaWAN network using OTAA?
I'm trying to make LoRA node to use Spreading Factor SF12, because the default one is SF7. I know that in the PHY layer we can change Radio configurations. There are several examples to change between the different sub-GHz frequency bands, however, I can't find one on how to change the LoRa modulation SF between 7 and 12 and with a bandwidth of 125 kHz.
I'm using an SX1276 radio at EU 868 MHz config.
In the source code you can find the SF7-12 different configurations, but there is not a clear way to set it up. These configs are the definitions (#define) DR_0, DR_, etc ).
In the configuration file in the Phy part you find some example like this:
"phy": {
"help": "LoRa PHY region. 0 = EU868 (default), 1 = AS923,
2 = AU915, 3 = CN470, 4 = CN779, 5 = EU433,
6 = IN865, 7 = KR920, 8 = US915, 9 = US915_HYBRID",
"value": "0"
},
But there is no examples or description for the Spreading Factor.
I would like to change it via source code, rather than the configuration file.
EDIT 1:
after Jon's answer, I add the following lines, but still not forcing the SF12 Joins.
retcode = lorawan.disable_adaptive_datarate ();
retcode = lorawan.set_datarate (0); // DR_0
Call:
lorawan.set_datarate(0); // SF12 125 KHz
Make sure to:
Disable ADR.
Either use ABP, or call the function above in the JOIN_SUCCESS event handler. This is because join procedure always starts at SF7, and then keeps the data rate on which the join succeeded.
This might be a silly mistake from my side that I have overlooked but I'm fairly new to UVM and I tried tinkering with my code for a while before this. I'm trying to send in a stream of 8 bit data within a packet using Data valid stall protocol from my UVM driver to the DUT. I'm facing an issue with my input monitor not being able to pick up these transactions that are driven.
I have a while loop with a condition that the valid bit must be high and the stall bit should be low. As long as this condition holds good, the monitor needs to pick up the data byte and push into the queue. I know for a fact that the data is being picked up and pushed to a queue as I used $display statements along the way. The problem is arising once all the data bytes are received and the valid bit goes low. Ideally, this should cause the exit from the while loop but isn't doing so. Any help here would be appreciated. I have attached a snippet of the code below. Thanks in advance.
virtual task main_phase (uvm_phase phase);
$display("Run phase of input monitor");
collect_transfer();
endtask: main_phase
virtual task collect_transfer();
fork
forever begin
wait_for_valid_transaction_cycle();
create_and_populate_pkt();
broadcast_pkt();
#(iP0_vif.cb_iP0_MON);
end
join_none
endtask: collect_transfer
virtual task wait_for_valid_transaction_cycle();
wait(iP0_vif.cb_iP0_MON.ip_valid && ~iP0_vif.cb_iP0_MON.ip_stall);
endtask: wait_for_valid_transaction_cycle
virtual task create_and_populate_pkt();
pkt = Router_seq_item :: type_id :: create("pkt");
pkt.valid = iP0_vif.cb_iP0_MON.ip_valid;
pkt.sop = iP0_vif.cb_iP0_MON.ip_sop;
$display("before data collection");
while(iP0_vif.cb_iP0_MON.ip_valid === `HIGH && iP0_vif.cb_iP0_MON.ip_stall === `LOW) begin
$display("After checking for stall");
pkt.data = iP0_vif.cb_iP0_MON.ip_data;
$display(pkt.data);
pkt.data_q.push_front(pkt.data);
pkt.eop = iP0_vif.cb_iP0_MON.ip_eop;
$display("print check in input monitor # time = %0t", $time);
#(iP0_vif.cb_iP0_MON);
end
$display("before printing input packet from monitor");
Check_for_port_route_and_populate_packet_field(pkt);
print_packet(pkt);
endtask: create_and_populate_pkt
The $display statement "before printing input packet from monitor" is not being displayed.
HIGH is defined as a binary 1 and LOW is defined as a binary 0.
The output of the code in terms of display statements is as below.
before data collection
before checking for stall
After checking for stall
2
print check in input monitor # time = 105
before checking for stall
After checking for stall
1
print check in input monitor # time = 115
before checking for stall
After checking for stall
3
print check in input monitor # time = 125
It's possible that the main phase objection is being dropped elsewhere in your environment. UVM will automatically kill any threads that were spawned during a phase when it ends.
To fix this, do not object to the main phase in your monitor. Objecting to that phase is the responsibility of the threads creating the stimulus. Instead, you should be launching this monitor during the run_phase, which will ensure that your loop is not killed until the end of simulation.
Also, during the shutdown phase, you will want your monitor to object whenever it is currently seeing a packet. This will ensure that simulation doesn't end as soon as stimulus has been sent in, giving your other monitors time to collect responses from the DUT.
-1
down vote
I work with the Sim808 module I'm going to Sleep, but it does not go down !!!!! With the Sim800, I'm going to sleep! I use the AT + CSCLK = 1 command Streaming on SIM808 Before 26 mAh later 26 mA Streaming on SIM800 Before 16 mAh later 1 mA
Meanwhile, in both modules after the SLEEP, the serial communication is dropped, indicating that the command is sent correctly to the module. So why does not crack in SMI808.
Please give me guidance. Thank you
Hello
In datasheet
If you use sleep mode, the power consumption is low.
But for my module, the circuit current does not change. !!!
Steps on the module:
1-circuit current of 26 mA
2. Sending code AT + CSCLK = 1
3-Serial connection disconnected.
4. In fact, the module is in sleep mode.
5-Circuit current of 26 mA
Why before and after sleep, the current circuit is 26 mAh !!!!! ????
According to the data, the circuit must be 1 mAh. !!!!
this is my first question here.
i have ht12d ic connected to pic16f84a.. VT pin connected to Rb0/int pin of pic.. and the 4 data lines are connected to 4 pins of PortB.. also am having a digital sensor also connected to rb0/int pin.. whenever there is interrupt either from the decoder ic or the sensor i ve managed to deal with these two sources of interrupts.. the problem is ht12d pins remains latched to last signal and don't return to default state.. in fact am using the status of these 4 pins to differentiate between the two interrupts.. for example :
proto:
if portb.b1 is 1 then its command 1;
if portb.b2 is 1 then its command2;
if portb.b3 is 1 then its command3;
if portb.b4 is 1 then its command4;
if they are all 0, then it's sensor interrupt ;
is there any way to reset ht12d data pins to default state after each valid transmission..