Arvest

Sending out value from memory based on encoder value

13 posts in this topic

Hello, quite new to PLC's, currently figuring out if / which PLC is the way to go for my application:

I'm construction a machine with a two axis (X/Z) with 88 valves mounted on them. The X axis makes a scanning motion, and after every pass, the Z axis moves down 2.5 mm. When the X-axis moves, the valves need to switch in a certain pattern, opening / closing with a resolution of 2.5 mm, based on the current X and Z-position (i.e. encoder values). My goal is to move around 0.25m/s, so they would switch around 100 times per second (i.e. every 10ms). I want to be able to upload the pattern via Ethernet connection from my PC. The valves will most probably be switched through a Modbus RTU digital I/O unit(s)

I ended up with the Modicon M241 as a nice PLC with the right I/O capabilites and features for my application. However, I don't know if it is suitable, as I am unable to find out how the whole uploading a pattern to memory, and then retrieving values one by one from memory during operation would work (i.e. which instructions should I use in my PLC program?)

 

Share this post


Link to post
Share on other sites

This sounds like a typical PLC application.  You will almost certainly be disappointed trying to switch valves that fast with Modbus RTU.  You will want those coils wired individually to output modules mounted directly to the PLC's CPU.

I'm not familiar enough with the Modicon family's motion control capabilities to know if it will be responsive enough.

Share this post


Link to post
Share on other sites

One more note:  when switching solenoid coils that fast, use heavy-duty Metal-Oxide-Varister suppressors on the coils instead of flyback diodes.  Flyback diodes greatly lengthen the time it takes for solenoids to turn OFF.  Probably too much for 10ms cycles.  MOVs apply reverse voltage to the coil such that they turn off about as quickly as they turn on.

Some digital output modules from various brands include flyback diodes right in the digital output.  You must not use that kind of output module, for this same reason.

Share this post


Link to post
Share on other sites

a very good point, i would add that MOVs do not apply reverse voltage, they are passive component and do not store energy - they just conduct more at some higher voltage. depending on used product, this value is different. the higher the clamping voltage is, the shorter the pulse is (turns of faster). diode has Vf of only 0.7V so the clipping on 24V solenoid occurs at 24.7V. That is extremely low and takes longer to switch off. But with MOV it may be at 36V or so. using Zener diodes one can get the same effect which is why there are several options to choose from.

Share this post


Link to post
Share on other sites
3 hours ago, panic mode said:

MOVs do not apply reverse voltage, they are passive component and do not store energy

Well, the coil is the item storing energy, and producing the reverse voltage when the driving voltage quits.  With a diode, the reverse voltage peaks at ~0.7V.  With an MOV, that reverse voltage peaks at the MOV's breakdown rating. With neither diode nor MOV, that reverse voltage peaks at spark initiation in the wiring, or at the failure reverse voltage of the driving circuit. For the pedants among us engineers. (:

1 person likes this

Share this post


Link to post
Share on other sites
19 hours ago, pturmel said:

This sounds like a typical PLC application.  You will almost certainly be disappointed trying to switch valves that fast with Modbus RTU.  You will want those coils wired individually to output modules mounted directly to the PLC's CPU.

I'm not familiar enough with the Modicon family's motion control capabilities to know if it will be responsive enough.

Thanks for the reply. I still need to figure out how to get that pattern values into my PLC program, but that is (in this case) a more specific Modicon question.

You are right about the Modsbus RTU being too slow. I have used Modbus in the past to provide corrections to a robot arm in real time, but that was Modbus TCP. I mixed the two up. Modbus TCP should be fast enough, depending on how effecient the PLC is at getting that signal out there.

Direct connection to the PLC would not be the preferred option because of all the cabling involved. A RTU would be a much lighter and simpler option.

Regarding the coils:

currently we use a normal flyback diode, and this achieves a 7 ms closing time. I will investigate using a MOV or Zener in the design, but I believe not the coil, but the spring inside of the valve is the limiting factor wrt the closing time.

Share this post


Link to post
Share on other sites
5 hours ago, Arvest said:

but I believe not the coil, but the spring inside of the valve is the limiting factor wrt the closing time

Measure carefully.  The bulk of the time caused by the diode will be between output turn-off and the valve beginning to close.

Share this post


Link to post
Share on other sites

spring only gets to do something after there is no more current in the coil (magnetic field collapses). as long as coil is energized, spring is not in control. so after output is off, current still flows through solenoid (but now it is going through diode, not the output). this is due energy stored in solenoid and duration is affected by characteristics of suppression device. and as mentioned already, connecting MOV or Zener across solenoid will not produce any meaningful difference if output has own built in diode (and normally they do!). and if not but you choose MOV and Zener with too high breakdown voltage, the output device will get damaged. 

 

1 person likes this

Share this post


Link to post
Share on other sites

In the mean time I have gone through a large part of the documentation and tutorial videos on the Schneider Electric Modicon M241, but am unable to find a description of how to implement my use case, as I described in my initial post: download a program/instruction set (which contains the information on when which valve should open), and have the PLC program look up the data based on a encoder value. I can find things about 'recipes', but these seem to be mainly used as varying a few variables, like the number of holes you want, or the time to mix something. The program I need to load will be about 15-20 megabytes, consisting of a lookup table to look up a 16-bit value for each X,Y,Z value.

Nowhere I can find anything on using a PLC like that. Would you have any pointers where to find more information? How is this normally implemented?

Share this post


Link to post
Share on other sites

i am not quire sure i understand the details of what you are trying to do. for example what is the total work area (length of X/Z)? that could explain why would data file need to be so large.

20mb grouped in 16bit points means up tp 10485760 points or canvas of 3238x3238 pixels. so yeah.. to me it sounds like you are developing something that paints murals or billboards and the 88 valves are an array of spray nozzles for different colors. if so then why not use just few of them (CMYK or RGBWK) instead of 88. also 16bit value is sufficient to control 16 points but it is not sufficient for addressing 88 valves that you require. that would require 88bit (or 96 bit).

conventional industrial PLCs are not very good for this. one of the limitations is scan speed as well as IO speed. also most PLCs would have hard time with that large data file but chances are things can be optimized.

so getting to know real requirement is the key. next one need to focus on hardware. perhaps there is no need to dump entire file to PLC - how about sending enough of data for one line scan only?

if commercially available products do not meet the needs, one can make custom hardware to do pretty much anything.

 

 

Share this post


Link to post
Share on other sites
2 hours ago, Arvest said:

The program I need to load will be about 15-20 megabytes, consisting of a lookup table to look up a 16-bit value for each X,Y,Z value.

Yeah, that calls for a SCADA system and database to feed the PLC.  The SCADA would load several centimeters of data into a ring buffer in the PLC, then dynamically load more from the database as the servo advances.

This is exceedingly non-trivial.

Share this post


Link to post
Share on other sites

you have deduced already pretty much what we are trying to do, but let me elaborate:

We are building a printer for 3D printing concrete using powder bed technology. It has a XY gantry (although the X axis is restrained to only 10 mm  of motion) with as a Z axis a platform (the bottom of the container in which we print) that can be lowered (hydraulic system). The array of nozzles is mounted along the X axis.

The motion that the machine makes is relatively simple: the Y axis makes scanning motion, and at the end of a scan, the X axis moves 2.5 mm to the side, and the Y axis returns. This is repeated again, as the nozzles are 10 mm apart. Then the Z platform (the print bed) moves down 2.5 mm, another layer of dry material is applied through the U-axis, and the process is repeated.

As said, we use an array of 88 nozzles to which just eject water. We use so many nozzles in a row to speed up the process. Our resolution is 2.5mm, and the volume we print is roughly 1x1x1 meter, which means 400x400x400=64 million points. (Also you are right that 16 bit is not sufficient for addressing 88 valves. I mispoke, it of course needs 11 bytes to encode it). But basically it all boils down to roughly 64M / 8 = ~8Mbyte, plus some overhead (other equipment also needs to be controlled during depositing of the layers).

The valve behavior look-up table is generated from some slicer software, which is written by ourselves, so we have full control over the output format.

 

Edited by Arvest

Share this post


Link to post
Share on other sites

so doing 4 or 5 passes can give you X axis range of 880-1100mm 

so some measurements are needed to verify data transfer, PLC scan time, IO refresh time and valve response time.

modern PLCs are quire fast, Ethernet messages are not big deal if you transfer data in reasonably sized chunks. transferring all at once requires a lot of memory and also it is going to take long time.

Depending on used platform and implementation details streaming may or may not be perfect because you also need to take care of pretty tight timing on numerous outputs.

the PLC logic should be fast. this means not dealing with valves individually (bit by bit). it would be better to use block move to write data to all outputs at once, wait a bit (make this adjustable), then clear all outputs the same way. and this could be done in an interrupt to get best possible accuracy.

If the streaming of data does produce issues (scan time glitches and inaccuracies in the print) one options is to simply not transmit while print is in progress. In this case you would need to transfer and buffer all the data for that one full pass in Y-direction and this is done every time before the Y axis moves - transfer would take place while X axis is moving because no print is in progress at that time. that means you would need to transfer and buffer 11bytes * 400 samples = 4400 bytes or 2200 words. all of this is very doable.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now