SCL direct output changes?

sommers9

Member
Join Date
Mar 2016
Location
Here
Posts
10
I'm currently investigating the usage of a Siemens S7-315 PLC to control a row of "shift registers".

I would use one data signal and one clock signal and attempt to send data in a serial fashion.

(A very crude timing diagram below:)
Data _-___-_-_-_-__-
Clock_-_-_-_-_-_-_-_-
Data: 1 0 1 1 1 1 0 1

Essentially, the clock will indicate the speed of the transfer. When the clock goes high, the data line becomes valid. And the shift register will push in a 1 or 0 depending on the status of the data line.

With regular scan times of the PLC (>2ms) clocking in the signals will simply take too long. So I was curious if using SCL (code) in the PLC could directly change the outputs. To achieve a speed of around <0,2ms.

Is this possible in SCL?
I've contacted Siemens, and they didn't know of any interfacing modules which are capable of "Serial Peripheral Interface" (SPI).
 
SPI interface is typically used on microcontrollers and not PLCs. It's high speed, low voltage, very short distance.

Maybe there is another and better solution to your problem.
What exactly are you trying to accomplish?
 
I agree with the other posters that what you are trying to do more or less doesn't make sense in the PLC world.

Siemens has RS232 cards and RS485 cards, but you don't get to control the clock. You just ask the card to send the data, and it does when it gets around to it. You can configure the buad rates and other communications parameters, however, to ensure that it matches its partners.

If you want to do very fast IO control with an S7, look into something like Profinet IRT. This allows you to have very fast bus updates, while minimizing jitter. However, the device you are communicating to needs to be able to talk Profinet as well.
 
I was trying to interface with a digital LED strip (not an analog one).

Many thanks for the reactions, I'll note them in my research (if you don't want me to, please contact/react so).

The idea behind this was to actually "take out the Arduino" of the current system. Since the Arduino brings in additional "maintenance". It's also more of an experiment and/or research. So that's why I'm indeed going a bit against the idea of PLC's.

@KalleOlsen
I did actually find resources on the PLC being cyclic (but not from Siemens self) so thanks on that, will fit nice in my research.
But, it does not (clearly) state that SCL is also handled in the same cyclic manner. I've heard that you can use loops within SCL and might be able to set/reset outputs in that same loop. (would effectively give you <1ms latency)

@Pete.S.
I agree there are/should be better options, I'm actually also checking those. For my research it's actually important to check this single possibility. And SCL gave me some hope on higher speeds (since it might not be cyclic?). It's more of a "proof of concept" or theoretical point (though if it works in theory, I'll try it practically).

@mk42
The S7-315 2-PN/DP has a profibus DP built-in, so I could use that to interface with a microcontroller. But the point of the question is rather theoretical/proof of concept. Microcontrollers aren't that useable for ProfiNet I guess. But might check one of those Ertec 200P things of Siemens?
 
If you're trying to replace an arduino, then what you said makes a lot of sense. The trick will be getting it to work. Are you doing anything else with the PLC, or just controlling one LED?

@KalleOlsen
I did actually find resources on the PLC being cyclic (but not from Siemens self) so thanks on that, will fit nice in my research.
But, it does not (clearly) state that SCL is also handled in the same cyclic manner. I've heard that you can use loops within SCL and might be able to set/reset outputs in that same loop. (would effectively give you <1ms latency)

As a preface: the plus side of the PLC is that it handles the serial comms for you, so all you need to do is give it a data buffer and it sends it for you, over whatever protocol you've selected in the HW config of the interface. You don't need to worry about sub millisecond timing for a serial data clock.

To your point: In the siemens world, code from any languague is treated like any other. You CAN use loops in SCL, but you can do loops in LAD, too. Either way, the loop has to finish eventually so that the PLC can go on to scan the rest of the code. The important thing is that the PLC can only execute one block at a time. If you do 100 loops in SCL, you will get good response for a while, but it will eventually go back to processing the rest of the code, and the SCL won't be called for awhile. Then you basically get no response.

BUT, there is a better way to do it:
The above is true if you execute the code all out of the main PLC scan (OB1) at the same priority. If you use a cyclic interrupt, then you can have some code that interrupts the main PLC scan, to quickly run your SCL algorithm, and then drop back to the main PLC scan right where it left off. These cyclic interrupts (like OB35) can be called at a configurable interval, although the minimum in a 315 is 1ms. If you use a 1500, the cyclic interrupts can be as often as 500us to 100us, depending which CPU you get.

@mk42
The S7-315 2-PN/DP has a profibus DP built-in, so I could use that to interface with a microcontroller. But the point of the question is rather theoretical/proof of concept. Microcontrollers aren't that useable for ProfiNet I guess. But might check one of those Ertec 200P things of Siemens?

Ultimately, what device are you trying to interface with? Is the microcontroller onboard the LED strip?

Yes, the 315 has Profibus built in, so if your microcontroller supports that, you're fine. However, the port only talks Profibus DP, not general RS485. If the microcontroller only supports generic RS485, you might need to either get a serial card or develop/purchase a Profibus stack for the microcontroller. Siemens does have chips you can use for Profibus and profinet, but you would then have to integrate it into your LED strip, and I'm not sure if anyone on this forum has experience with something like that.

If you want to use a PLC, it might be simpler (and possibly cheaper) to get a new analog LED strip than to implement the comms to the microcontroller.
 
One issue is the manipulation of the outputs from the program. That could maybe be done if the code is run in a high-pri task.
The output byte must be copied to the pheripheral byte after each scan.

Another, 'worse' issue is the delay time from the output is manipulated until the output card responds. The shift time from on to off and reverse can be different. I/O on the DP would be even more unpredictable, as the update cycles would be asynchronus.

You might get best off by using a Vipa (it's an S7300 clone) with the Speed7-bus and a 'left side' mounted output card.

Good luck
Kalle
 
If you stretch to a 319 this will allow you to set the timed interrupt at 500uS. Profinet I/O can be set to update at 500us. The 2PULSE module allows the outputs to switch at 5kHz. Never done it, but looks feasible.

319.jpg
 
@MK42 Yup, should've mentioned replacing the Arduino.
They do have a program running on the PLC, but the first step in the research would be controlling it from a clean PLC.

Interrupts do give an opportunity.

With your point on SCL and LAD being handled in the same way (which is actually very cool). Do you also mean that the changing of the output will only be done after the SCL loop finished? Then only the fast(er) interrupts do give a chance, but will decrease reliability of possible other programs running in the background.

The part on RS-485 / Profibus is actually another option that I will be researching. Which looks like a more solid way.
It does involve the need of using a microcontroller, but building a custom PCB would allow something more smaller, efficiently and "professional".
I'll look into hardware or software "decoding" of the profibus for that, but it's a whole other case indeed.

The LED strips will be used to indicate specific "parts". Thus they should be able to light up partially. Which isn't a feature of analog strips. I'm going to add it to my research and recommendation though :)

I believe Profibus could be handled in software, but might not be all too reliable (and hard to get certified), but that isn't a concern for this research. The LED strips are not a safety risk in any way.
Profinet would be one hell of a job to implement in software. I will atleast need a hardware ethernet receiver or something like an XPORT profinet receiver
I have (in a previous project) used an XPORT ethernet receiver with a microcontroller, so I should be able to handle that.

My current options are:
Hacky SPI software implementation in PLC using interrupts (maybe get a bigger/faster PLC)
(Software/hardware) Profibus + microcontroller
(hardware) Profibus + microcontroller
Check the internet for an existing device with this possibilities.

@KalleOlsen

It doens't matter when I start sending to the LED strip (100+ ms)
But the actual message will/might consist out of 10.000 bits, so I would need a rate higher as 1 bit / ms.

I would prefer the PLC to start sending within 100ms and sent 10.000bits in another 100ms.
But that's also the reason why I would need a microcontroller. I can send profinet/bus commands that will make the microcontroller (hardware) rapidly update the bit-array. By clocking out the bits.

My research was to exclude the Arduino, as it brings in additional "problems". The company does not want to use Arduino's since:
- They might stop working (and no on-site engineers now how to fix Arduino's).
- They want to exclude as much of external controllers, also because of the reasons above.
- It takes more time to set up the system, because you also have to set up the Arduino etc. (You also have to program the Arduino before installing)
- When building/expanding/renewing the system, they need C/C++ programmers to update/change the Arduino code.
So they want to make the PLC do Arduino stuff :) or ultimately have done a very well research on why a PLC can't do it.
And then I can show them an option like a microcontroller receiving commands from an PLC (so the PLC is the controller) and the microcontroller is just a "slave device" which has little "knowledge".

@L D[AR2,P#0.0]
The 2PULSE is a PWM module, which does not have the possibility to send "data". It'll only send an 101010101 signal. Which is usefull for analog LED strips.
 
The 2PULSE is a PWM module, which does not have the possibility to send "data". It'll only send an 101010101 signal. Which is usefull for analog LED strips.

The 2PULSE can operate in various modes, PWM being one of them. You can also set them up to control the digital outputs directly.
 

Similar Topics

Hi, I am facing invalid data type when i compile SCL and no luck in finding any old threads? could point me out to right direction? Thanks...
Replies
3
Views
2,163
Hello, I am currently forced to use s7-1200 (6ES7214-1AG40-0XB0) PLC for one small project. I do have some experience with S7-300/400 mostly in...
Replies
6
Views
5,039
Hi all In a step7 SCL FB (NOT TIA portal) , I have declared many variables as IEC timers (SFB4). Now I need to iterate this variables (hundreds...
Replies
15
Views
7,838
Hi all, Trying to figure out how to convert a block I created in STL to SCL and I run into problems from line one, lol. Is there a way to input...
Replies
10
Views
3,216
Hi I am trying to read data from various DB's So "DB_HMI".Data1 := DB[PARAM].Data1 etc where PARAM = 1 to 99
Replies
8
Views
4,050
Back
Top Bottom