Red MU issue in VMAT with Elekta

89 views
Skip to first unread message

Pedro

unread,
Dec 2, 2021, 8:48:37 AM12/2/21
to pinnacle3-users
Hello, we have Pinnacle 16.2 and we are quite fed up with the "red MU" issue that appears with the Elekta MLC (Pinnacle incorrectly thinks some arcs are undeliverable). Sometimes this happens even without modifiying the prescription nor anything after the optimization. According to a discussion in this group a few years ago it was related with how Pinnacle manages the guard leaves if I recall well. The workaround is not very orthodox, and potentially it may lead to serious errors in case of a typing mistake if the trial is not carefully reviewed after using the workaround.

But we are getting inconclusive information about this: officially there is a known issue and still no date for the resolution and it is still necessary to use the workaround. But a user with the last version of Pinnacle (16.4) told me they don't find this issue.

So we would like to hear about firsthand experience from other people using the combo Agility+Pinnacle. Do you know if the probability of occurrence of this error depends on the limits set in Pinnacle for dynamic delivery? Or on the optimization parameters? Have you seen it in 16.4?

We can understand that any TPS has some bugs or glitches, but it is surprising that this one is known for years and apparently it has not been solved yet. Toghether with a few other little nuisances it is one of the reasons why we are considering the option to move to a different TPS.

Thanks in advance! 

Pedro

Gregory Bolard

unread,
Dec 2, 2021, 12:19:10 PM12/2/21
to pinnacl...@googlegroups.com
Hello

Red MUs is indeed something solved in 16.4 and more generally DICOM export is always possible for VMAT beams.

Best regards,
Gregory 
 

De : pinnacl...@googlegroups.com <pinnacl...@googlegroups.com> de la part de Pedro <palme...@gmail.com>
Envoyé : jeudi, décembre 2, 2021 2:48 PM
À : pinnacle3-users
Objet : [p3rtp] Red MU issue in VMAT with Elekta
 
--
--
You received this message because you are subscribed to the Google
Groups "pinnacle3-users" group.
To post to this group, send email to pinnacl...@googlegroups.com
To subscribe to this group, send email to
pinnacle3-us...@googlegroups.com
To unsubscribe from this group, send email to
pinnacle3-use...@googlegroups.com
For more options, visit this group at
http://groups.google.com/group/pinnacle3-users?hl=en

---
You received this message because you are subscribed to the Google Groups "pinnacle3-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pinnacle3-use...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/pinnacle3-users/c24b0ab7-5767-4ca7-9128-e65680631bedn%40googlegroups.com.

Fabien Boune

unread,
Dec 6, 2021, 10:57:48 AM12/6/21
to pinnacle3-users
Hello? Pedro , yes the occurrence depends on both there are some values used for modelisation that can lead to that like the minimum dynamic leaf gap if i remember well, and the maximum speed entered for the machine not the one for your plan. 
I noticed when I do a plan with a spacing of 2° it is almost systematic to have the RED MU , but when doing a plan with a 4° spacing ,more than half of the plans are  ok without red MU.

I'm using 16.4 both manually and Evolution  spacing 2° grid 0.3cm , on more than 300 plans, I NEVER had the red MU , unless you play with the prescription afterwards. like ( normalizing to 95% etc etc) and with the 16.4 it show on wich Control point you have the "violation" of speed  gantry rate ( deg/sec ) or the leaf speed (cm/sec). 
One of them is colored in red if your prescription modification violates some constraints.

We can understand that any TPS has some bugs or glitches, but it is surprising that this one is known for years and apparently it has not been solved yet. Toghether with a few other little nuisances it is one of the reasons why we are considering the option to move to a different TPS.

I gonna make the devil's advocate here , i think one the reason some bugs or glitches have not been solved til these days , is because the optimizer was not their "property" and the "just" coded around it , and now the made their own optimizer  they can solve some issues  like 
In autoplan no matter with minimum segment area you asked ... you will have a final plan with some CP area below this value .. not anymore in 16.4. 
Same with the maximum delivery time .; now if you ask 90 it's gonna be 90. 
Doing a plan with auto planning the Modulation of the plan is some kind of surprise at the end .. nor anymore you can choose the lvl of freedom for modulation and MU etc etc 
And more i'm not even talking of the new speed... doing a pelvis with node in 16.2 and in 16.4 ..

I Think you should try 16.4 and see. 

Hope i helped a little.

--
Reply all
Reply to author
Forward
0 new messages