Delta PLC High Scan Time due to analog Modules

I am using a Delta 28SV2 PLC, with additional 3 digital IO Modules, Plus one 4 channel analog input module and one 4 channel analog output module out of which 2 channels on the analog input side and 4 channels on the analog output side are being used. Now the issue is, as soon as I start using the analog input and output in my logic, the PLC scan time jumps from 2 ms to 10.6 ms which is very high for my application. Nonetheless, I even tried erasing the rest of the logic, just keeping the 2 lines of logic which enable to get analog input within the PLC and give out a value to the analog output and the scan time remains at about 8 ms. this is without having any other line of logic, just the FROM and TO instruction in delta PLC to read and write the relevant values. All registers used are unretentive, as using retentive registers in the FROM and TO further doubles the scan time. However, even having 8ms scan time just for analog input and output seems very high, and causes issues in my application. Am I doing something wrong or is this an issue with Delta PLCs or this particular model in general? will the arrangement of modules with relation to the PLC make any difference in this?
 
Whilst not having a great of experience with Delta PLC's, historically a scan time of up to 30ms (Milliseconds) was considered average.
In your case, one suspects the scan time is intentionally slowed (10ms is considered reasonable modern day scan time) to match / exceed conversion times in the Analog I/O modules.
Even the most experienced Software Engineers have been caught out processing Analogue values before a change {in Value} has been processed by PLC hardware.

It is always prudent to write software which is not time sensitive - if it is, then you have to consider how the PLC hardware / firmware functions. Processing Analogue values before a change {in Value} has been processed by PLC hardware will probably give false results.
 
Whilst not having a great of experience with Delta PLC's, historically a scan time of up to 30ms (Milliseconds) was considered average.
In your case, one suspects the scan time is intentionally slowed (10ms is considered reasonable modern day scan time) to match / exceed conversion times in the Analog I/O modules.
Even the most experienced Software Engineers have been caught out processing Analogue values before a change {in Value} has been processed by PLC hardware.

It is always prudent to write software which is not time sensitive - if it is, then you have to consider how the PLC hardware / firmware functions. Processing Analogue values before a change {in Value} has been processed by PLC hardware will probably give false results.
30ms or even 10ms might cut it in process logic environments but even 10ms is quite long for standalone High Speed industrial machinery, let alone 30. At 30ms the PLC keeps skipping important inputs and the delay in energizing outputs is evident to the eye without requiring any special instruments. Of course, this is only for high speed machinery, which is say running above 120 to 130 cycles per min and 180 to 200 cycles per min on average.
Coming back on point, the reason I am deliberating on this is because apparently this model, DVP28SV2 Is Delta's high end PLC specially aimed at high speed packaging machinery, most which require analog feed back and perform analog speed control at some point or the other, hence, it's prudent to atleast assume, that their might be some peculiarity to setting up analog modules with this PLC and still be able to preserve the scan time or atleast bring it down to a reasonable level.
 
https://www.deltaww.com/en-us/products/PLC-Programmable-Logic-Controllers/ALL/
Delta DVP
"Delta's DVP series programmable logic controllers offer high-speed, stable and highly reliable applications in all kinds of industrial automation machines. In addition to fast logic operation, bountiful instructions and multiple function cards"...

That description could equally apply to any other make of PLC - depending on what high-speed you have in mind. High speed / short digital pulse inputs can be catered for by high speed counters..... Analogue you are limited to A-D conversion times.
What high speed machinery application requires such short - perhaps we could assist.
The only time I've managed to beat PLC response times, is dedicated hardware to suit the machine and software in 'Assembler' (aka machine code).
 
Well, the machine in question is a high speed feed to length bag making application primarily and intended to run constantly at 200 cycles per min and the main operation is controlled by differently times cams on the main shaft which is rotating at 200 rpm. The RPM of the main shaft will be equal to cycles per min. There are Cams installed on the main shaft at different degrees of rotation, which give 3 primary inputs, the start and stop signal for the servo that will feed the material, the stopping position of the shaft when the machine is to be stopped and also acts as a counter for number of cycles completed and one additional cam to slow down the machine before bringing it to a stop when the stop command is queued. There are many other digital inputs, but the ones mentioned above are the critical ones which are affected and ultimately affect the relevant outputs in the machine which need to be energized as fast as possible once their inputs are scanned. Now at 200 cyclespermin, the entire cycle is 300 ms and there are a couple of outputs which need to be on for only 1/4th time of the cycle which would be 75ms, now in these outputs out of 75 ms even if 10.5 ms is lost in execution time, that's almost 15 percent time lost.
 
Not to mention, the PLC sometimes skips scanning of edge triggers. The counter issue we've temporarily gotten away with by using a hardware high speed counter, the servo delay by routing the input trigger directly to servo drive instead of the PLC, but which now necessitates having to use only the Delta A2 drive, which is capable of internal position control mode without pulses from the PLC, but on the downside we lose a lot of fine control for the servo such as scaling acceleration and deceleration times scaled to the feed length and speed of machine, plus the servo even triggers when the automatic cycle is not on and the machine is jogged manually
 
It appears to me that you need:
A rotary encoder and a field-programmable gate array (FPGA).

https://uk.rs-online.com/web/p/motion-control-sensors/2013642
https://docs.rs-online.com/1faa/A700000006916854.pdf
https://uk.rs-online.com/web/c/rasp...ingle-board-computers/fpga-development-tools/
The rotary encoder would be end -of-shaft sensor spinning at shaft speed, giving 100pulsesperrevolution (PPR).

The FPGA is harder to determine without futher details: but it would need at least 6 inputs from the encoder and be capable of decoding rotary data; and additional inputs from your process with outputs being programmable again to suit your process.
The 'arduino-development-tools' is relatively cheap but may be suitable if you have an arduino CPU.

https://en.wikipedia.org/wiki/Programmable_Array_Logic
PAL's and FPGA's have been available for some time and are an interesting solution for many applications.
 
Top