Using a Dedicated Controller for Improved Resolution in a Nozzle Array System?

[piter]

Hello everyone,

I'm working on a project that involves controlling an array of nozzles within a CNC environment, where the nozzles travel along a linear path at a constant speed and a given angle. The objective is to activate all nozzles in unison along a line perpendicular to their direction of travel (see image). This control is achieved through G-code for movement commands and M functions for turning each nozzle on or off.



The core challenge I'm facing is achieving precise synchronisation between the nozzles' motion and their activation/deactivation, especially considering the inherent delay in the hardware's response time. The current setup has the nozzles travelling at a speed of 500 mm/s, with the system's PLC operating at a cycle time of 1 ms. This configuration limits the system's resolution to about 0.5 mm, which is tied directly to the PLC's cycle time.

Considering these constraints, I'm contemplating whether adopting a dedicated controller with a faster cycle time might be a viable solution.
I'd appreciate your insights on the following questions:

- Feasibility: Is using a dedicated controller with a faster cycle time a practical approach to enhance resolution in this scenario? Have any of you implemented a similar solution in your experience?

- Recommendations: If you recommend going with a dedicated controller, are there specific models or brands that align well with these requirements? Consider an array of 24 individual nozzles.

- Alternatives: Alternatively, are there other strategies or technologies you'd suggest exploring to address the synchronisation and resolution challenges without necessarily switching to a different controller?

I'm keen to hear your thoughts, experiences, and any advice you can share on optimising the performance of such a system.
Thank you in advance for your help and recommendations!

 

[drbitboy]

What resolution is required or desired?

What is the noise level characteristic of the response times of activating a nozzle? I.e. what is the best resolution achievable?

P.S. cos(α) can be replaced by √(nP² - 1S²) / nP, to save one function call.

 

[drbitboy]

What resolution is required or desired?

What is the noise level characteristic of the response times of activating a nozzle? I.e. what is the best resolution achievable?

P.S. cos(α) can probably be replaced by √(nP² - 1S²) / nP, to replace two trig calls with one transcendental function call.

 

[piter]

Thanks for replying. The response time of the nozzles is 6 ms to switch ON and 8 ms to switch OFF. The CNC controller allows to "pre-call" M-functions, so the delay can be effectively addressed.

The main issue is that increasing nozzle density (or shortening niD in the diagram) will eventually lead to multiple calls in the same cycle. Given the actual dimensions of the effectors and the motion profile, the optimal cycle time to prevent it would be in the range 10-100 us.

 

[Peter Nachtwey]

Is this a product or a one-off machine. It makes a huge difference to how much effort/money you can put into this.

Synchronizing the motion of 24 or more nozzles isn't hard. The hard part is turning on and off the nozzles with the precision/timing you want. It looks like you need some dedicated hardware to turn the nozzles on and off as a function of location if you need to get as precise as you want. How repeatable is this? Can the nozzle timing be programmed into a FPGA?

 

[piter]

It's a one-off prototype for which we have some budget and time.
I agree that the challenge is controlling the nozzles. So far, I've been doing it within the CNC controller by using M-functions. This way, the computation required while operating is virtually none but, as I said before, I see problems in scaling the system to control denser nozzle arrays.

I will look into FPGAs, it looks like a good lead. As for mapping the nozzle state to the current TCP location, I guess the question there will be the tolerance to define whether the nozzle position is to be considered ON or OFF. In this scenario, would you imagine loading the "bitmap" in the internal memory of the FPGA card and using as input the position vector (x,y,a)?