Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.arch.embedded > #29764 > unrolled thread

Group Design

Back to article view | Back to comp.arch.embedded

Contents

  Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-07 18:46 -0700
    Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-07-07 19:02 -0700
      Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-07 20:36 -0700
        Re: Group Design David Brown <david.brown@hesbynett.no> - 2020-07-08 09:31 +0200
          Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 07:08 -0700
    Re: Group Design Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-07-08 14:13 +0200
      Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 07:19 -0700
        Re: Group Design Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-07-08 18:57 +0200
          Re: Group Design Theo <theom+news@chiark.greenend.org.uk> - 2020-07-08 18:28 +0100
          Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 11:12 -0700
            Re: Group Design Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-07-08 23:34 +0200
              Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-08 15:20 -0700
                Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-07-08 23:00 -0700
                Re: Group Design Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-07-10 10:09 +0200
                Re: Group Design Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-08-07 00:01 +0100
                  Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-06 17:37 -0700
                    Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-08-07 03:06 -0700
                  Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-06 21:50 -0400
                    Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-06 19:12 -0700
                      Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-06 22:27 -0400
                        Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-06 19:36 -0700
                          Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-06 23:39 -0400
                    Re: Group Design Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-08-07 12:30 +0100
                      Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-07 09:57 -0400
                        Re: Group Design Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-08-08 00:37 +0100
                          Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-07 20:29 -0400
                          Re: Group Design upsidedown@downunder.com - 2020-08-08 08:59 +0300
                          Re: Group Design David Brown <david.brown@hesbynett.no> - 2020-08-10 15:43 +0200
                            Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-10 09:18 -0700
                      Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-07 07:12 -0700
                        Re: Group Design Chris <xxx.syseng.yyy@gfsys.co.uk> - 2020-08-08 00:00 +0100
                          Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-08-07 20:30 -0400
                            Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-07 17:57 -0700
                          Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-07 17:56 -0700
                        Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-08-07 18:10 -0700
                          Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-07 19:43 -0700
                      Re: Group Design Dimiter_Popoff <dp@tgi-sci.com> - 2020-08-07 20:42 +0300
                        Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-08-07 13:48 -0700
        Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-07-08 14:11 -0700
        Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-07-09 04:25 -0400
          Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 11:37 -0700
            Re: Group Design Paul Rubin <no.email@nospam.invalid> - 2020-07-09 11:54 -0700
            Re: Group Design Tom Gardner <spamjunk@blueyonder.co.uk> - 2020-07-09 20:02 +0100
            Re: Group Design Phil Hobbs <pcdhSpamMeSenseless@electrooptical.net> - 2020-07-09 15:31 -0400
              Re: Group Design lasselangwadtchristensen@gmail.com - 2020-07-09 15:36 -0700
                Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 18:36 -0700
                  Re: Group Design Clifford Heath <no.spam@please.net> - 2020-07-10 16:17 +1000
                    Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 23:36 -0700
                      Re: Group Design Stef <stef33d@yahooI-N-V-A-L-I-D.com.invalid> - 2020-07-10 10:22 +0200
        Re: Group Design David Brown <david.brown@hesbynett.no> - 2020-07-09 14:40 +0200
    Re: Group Design John Speth <johnspeth@yahoo.com> - 2020-07-09 07:59 -0700
    Re: Group Design Don Y <blockedofcourse@foo.invalid> - 2020-07-09 18:33 -0700
      Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 19:01 -0700
        Re: Group Design Don Y <blockedofcourse@foo.invalid> - 2020-07-09 22:32 -0700
        Re: Group Design George Neuner <gneuner2@comcast.net> - 2020-07-10 17:36 -0400
          Re: Group Design Ed Prochak <edprochak@gmail.com> - 2020-07-14 11:09 -0700
            Re: Group Design George Neuner <gneuner2@comcast.net> - 2020-07-16 00:26 -0400
    Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-09 22:48 -0700
      Re: Group Design Don Y <blockedofcourse@foo.invalid> - 2020-07-09 23:53 -0700
        Re: Group Design Rick C <gnuarm.deletethisbit@gmail.com> - 2020-07-10 01:15 -0700
          Re: Group Design Don Y <blockedofcourse@foo.invalid> - 2020-07-10 02:22 -0700

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

#29800

On Thursday, July 9, 2020 at 4:25:32 AM UTC-4, Phil Hobbs wrote:
> On 2020-07-08 10:19, Rick C wrote:
> > On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote:
> >> On 2020-07-08 Rick C wrote in comp.arch.embedded:
> >>> Wow!  Designing in a group is strange.  I'm helping with the
> >>> design of a ventilator and it is a unique experience.  We have
> >>> people of many skill levels and talents, many I don't even know.
> >> 
> >> That is the good part of designing with a group. You can have many
> >> more talents and skills than can be combined in a single person.
> >> For a medical product like this you need medical, software,
> >> hardware, mechanical and lots more skills. Not something that can
> >> be found in one person very often.
> >> 
> >> <snip, some project frustrations etc.>
> >> 
> >>> I literally have no idea how they are ever going to get this
> >>> thing past any sort of approval process.  No one working on the
> >>> project even seems to understand what is required.
> >>> 
> >> 
> >> This is very worrying. As David already explained, documentation
> >> and approval is a very large part of medical device development.
> >> There is this famous Boeing quote about the weight of the paperwork
> >> required for a plane. I think you can extend this to medical
> >> devices as well.
> >> 
> >> Did they at least have a look at some standards that apply to
> >> ventilators to check what will be required? I would start off with
> >> IEC 60601-1, IEC 62304 and ISO 80601-2-12, make sure you use the
> >> latest versions. But there will be more.
> >> 
> >> And this should have been done before the first schematic was drawn
> >> or line of code was written. Some standards put requirements on the
> >> development process and you can not comply with those if you start
> >> your certification efforts after the development is completed.
> >> 
> >> 
> >>> I guess I'm a bit frustrated by the lack of organization.  I'd
> >>> like to step away, but the person acting as a leader seems to
> >>> want me in the group.
> >>> 
> >>> There is some work of my own I should do, so maybe I'll stick
> >>> around to get to rev 2 of the board and then step out.
> >>> 
> >> 
> >> If there has indeed been done nothing on the certification side, my
> >> feeling would be to step away as well.
> >> 
> >> 
> >>> I guess I'm used to working on my own.
> >>> 
> >> 
> >> Yes, than all is in your own hands. ;-)
> >> 
> >> But the advantage of a team is that you can concentrate on what you
> >> are good at and let others do what they are good at. And if the
> >> team is diverse and skilled enough (and properly led) the end
> >> result will be better that that of a single developer.
> >> 
> >> And I think a lot of medical device stuff can not be done by a
> >> single person. There are many cases where you need an (expert)
> >> reviewer in the process. Reviewing your own work is less than
> >> optimal. ;-)
> > 
> > It seems the UK has an abbreviated set of requirements for response
> > to COVID-19 and that is what they are mostly working with.  I forget
> > the name of it.
> > 
> > They do get advice from time to time from professionals in the field.
> > My main concern is a direction they are currently going in where more
> > and more valves, pressure relief, etc. is being added to the tubing
> > right at the patient.  I'm not sure how it all will be held in place.
> > That and how they plan to get this through the approval process.
> > 
> > I had a friend who worked on medical devices for a while before
> > getting out.  He said they required that you "prove" your design will
> > not hurt the patient in any way.  Hard to do with a ventilator.
> 
> IANAL, but the liability implications of that would be interfering with
> my sleep.

I guess you don't sleep well very often.  There will be no liability issues.  This group is not going to produce the machines.  They will hand the design off to a manufacturer who will produce, market and obtain approvals for the machine.  Liability will be all theirs.  

Most likely the machine will be totally redesigned anyway for cost reduction and to obtain approvals.  As a group this is not a highly knowledgeable design group.  I can't imagine this design will fly without rework. 

-- 

  Rick C.

  --- Get 1,000 miles of free Supercharging
  --- Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#29802

Rick C <gnuarm.deletethisbit@gmail.com> writes:
> Most likely the machine will be totally redesigned anyway for cost
> reduction and to obtain approvals.  As a group this is not a highly
> knowledgeable design group.  I can't imagine this design will fly
> without rework.

It's a medical device, so I think you mean cost enlargement rather than
reduction ;-).  But, if the design group doesn't know what it's doing
and is producing something that can't be used, then why are they
bothering in the first place?  What do they hope to contribute, and what
do they hope to gain?

[toc] | [prev] | [next] | [standalone]

#29803

On 09/07/20 19:37, Rick C wrote:
> On Thursday, July 9, 2020 at 4:25:32 AM UTC-4, Phil Hobbs wrote:
>> On 2020-07-08 10:19, Rick C wrote:
>>> On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote:
>>>> On 2020-07-08 Rick C wrote in comp.arch.embedded:
>>>>> Wow!  Designing in a group is strange.  I'm helping with the design
>>>>> of a ventilator and it is a unique experience.  We have people of
>>>>> many skill levels and talents, many I don't even know.
>>>> 
>>>> That is the good part of designing with a group. You can have many more
>>>> talents and skills than can be combined in a single person. For a
>>>> medical product like this you need medical, software, hardware,
>>>> mechanical and lots more skills. Not something that can be found in one
>>>> person very often.
>>>> 
>>>> <snip, some project frustrations etc.>
>>>> 
>>>>> I literally have no idea how they are ever going to get this thing
>>>>> past any sort of approval process.  No one working on the project
>>>>> even seems to understand what is required.
>>>>> 
>>>> 
>>>> This is very worrying. As David already explained, documentation and
>>>> approval is a very large part of medical device development. There is
>>>> this famous Boeing quote about the weight of the paperwork required for
>>>> a plane. I think you can extend this to medical devices as well.
>>>> 
>>>> Did they at least have a look at some standards that apply to 
>>>> ventilators to check what will be required? I would start off with IEC
>>>> 60601-1, IEC 62304 and ISO 80601-2-12, make sure you use the latest
>>>> versions. But there will be more.
>>>> 
>>>> And this should have been done before the first schematic was drawn or
>>>> line of code was written. Some standards put requirements on the 
>>>> development process and you can not comply with those if you start your
>>>> certification efforts after the development is completed.
>>>> 
>>>> 
>>>>> I guess I'm a bit frustrated by the lack of organization.  I'd like
>>>>> to step away, but the person acting as a leader seems to want me in
>>>>> the group.
>>>>> 
>>>>> There is some work of my own I should do, so maybe I'll stick around
>>>>> to get to rev 2 of the board and then step out.
>>>>> 
>>>> 
>>>> If there has indeed been done nothing on the certification side, my 
>>>> feeling would be to step away as well.
>>>> 
>>>> 
>>>>> I guess I'm used to working on my own.
>>>>> 
>>>> 
>>>> Yes, than all is in your own hands. ;-)
>>>> 
>>>> But the advantage of a team is that you can concentrate on what you are
>>>> good at and let others do what they are good at. And if the team is
>>>> diverse and skilled enough (and properly led) the end result will be
>>>> better that that of a single developer.
>>>> 
>>>> And I think a lot of medical device stuff can not be done by a single
>>>> person. There are many cases where you need an (expert) reviewer in the
>>>> process. Reviewing your own work is less than optimal. ;-)
>>> 
>>> It seems the UK has an abbreviated set of requirements for response to
>>> COVID-19 and that is what they are mostly working with.  I forget the
>>> name of it.
>>> 
>>> They do get advice from time to time from professionals in the field. My
>>> main concern is a direction they are currently going in where more and
>>> more valves, pressure relief, etc. is being added to the tubing right at
>>> the patient.  I'm not sure how it all will be held in place. That and how
>>> they plan to get this through the approval process.
>>> 
>>> I had a friend who worked on medical devices for a while before getting
>>> out.  He said they required that you "prove" your design will not hurt
>>> the patient in any way.  Hard to do with a ventilator.
>> 
>> IANAL, but the liability implications of that would be interfering with my
>> sleep.
> 
> I guess you don't sleep well very often.  There will be no liability issues.
> This group is not going to produce the machines.  They will hand the design
> off to a manufacturer who will produce, market and obtain approvals for the
> machine.  Liability will be all theirs.
> 
> Most likely the machine will be totally redesigned anyway for cost reduction
> and to obtain approvals.  As a group this is not a highly knowledgeable
> design group.  I can't imagine this design will fly without rework.

That doesn't make sense on so many levels that it isn't even worth refuting it!

[toc] | [prev] | [next] | [standalone]

#29804

On 2020-07-09 14:37, Rick C wrote:
> On Thursday, July 9, 2020 at 4:25:32 AM UTC-4, Phil Hobbs wrote:
>> On 2020-07-08 10:19, Rick C wrote:
>>> On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote:
>>>> On 2020-07-08 Rick C wrote in comp.arch.embedded:
>>>>> Wow!  Designing in a group is strange.  I'm helping with the 
>>>>> design of a ventilator and it is a unique experience.  We
>>>>> have people of many skill levels and talents, many I don't
>>>>> even know.
>>>> 
>>>> That is the good part of designing with a group. You can have
>>>> many more talents and skills than can be combined in a single
>>>> person. For a medical product like this you need medical,
>>>> software, hardware, mechanical and lots more skills. Not
>>>> something that can be found in one person very often.
>>>> 
>>>> <snip, some project frustrations etc.>
>>>> 
>>>>> I literally have no idea how they are ever going to get this 
>>>>> thing past any sort of approval process.  No one working on
>>>>> the project even seems to understand what is required.
>>>>> 
>>>> 
>>>> This is very worrying. As David already explained,
>>>> documentation and approval is a very large part of medical
>>>> device development. There is this famous Boeing quote about the
>>>> weight of the paperwork required for a plane. I think you can
>>>> extend this to medical devices as well.
>>>> 
>>>> Did they at least have a look at some standards that apply to 
>>>> ventilators to check what will be required? I would start off
>>>> with IEC 60601-1, IEC 62304 and ISO 80601-2-12, make sure you
>>>> use the latest versions. But there will be more.
>>>> 
>>>> And this should have been done before the first schematic was
>>>> drawn or line of code was written. Some standards put
>>>> requirements on the development process and you can not comply
>>>> with those if you start your certification efforts after the
>>>> development is completed.
>>>> 
>>>> 
>>>>> I guess I'm a bit frustrated by the lack of organization.
>>>>> I'd like to step away, but the person acting as a leader
>>>>> seems to want me in the group.
>>>>> 
>>>>> There is some work of my own I should do, so maybe I'll
>>>>> stick around to get to rev 2 of the board and then step out.
>>>>> 
>>>> 
>>>> If there has indeed been done nothing on the certification
>>>> side, my feeling would be to step away as well.
>>>> 
>>>> 
>>>>> I guess I'm used to working on my own.
>>>>> 
>>>> 
>>>> Yes, than all is in your own hands. ;-)
>>>> 
>>>> But the advantage of a team is that you can concentrate on what
>>>> you are good at and let others do what they are good at. And if
>>>> the team is diverse and skilled enough (and properly led) the
>>>> end result will be better that that of a single developer.
>>>> 
>>>> And I think a lot of medical device stuff can not be done by a 
>>>> single person. There are many cases where you need an (expert) 
>>>> reviewer in the process. Reviewing your own work is less than 
>>>> optimal. ;-)
>>> 
>>> It seems the UK has an abbreviated set of requirements for
>>> response to COVID-19 and that is what they are mostly working
>>> with.  I forget the name of it.
>>> 
>>> They do get advice from time to time from professionals in the
>>> field. My main concern is a direction they are currently going in
>>> where more and more valves, pressure relief, etc. is being added
>>> to the tubing right at the patient.  I'm not sure how it all will
>>> be held in place. That and how they plan to get this through the
>>> approval process.
>>> 
>>> I had a friend who worked on medical devices for a while before 
>>> getting out.  He said they required that you "prove" your design
>>> will not hurt the patient in any way.  Hard to do with a
>>> ventilator.
>> 
>> IANAL, but the liability implications of that would be interfering
>> with my sleep.
> 
> I guess you don't sleep well very often.  There will be no liability
> issues.  This group is not going to produce the machines.  They will
> hand the design off to a manufacturer who will produce, market and
> obtain approvals for the machine.  Liability will be all theirs.
> 
> Most likely the machine will be totally redesigned anyway for cost
> reduction and to obtain approvals.  As a group this is not a highly
> knowledgeable design group.  I can't imagine this design will fly
> without rework.
> 

Okay, so they aren't actually doing anything productive. That does tend 
to limit product liability. ;)

Cheers

Phil Hobbs

-- 
Dr Philip C D Hobbs
Principal Consultant
ElectroOptical Innovations LLC / Hobbs ElectroOptics
Optics, Electro-optics, Photonics, Analog Electronics
Briarcliff Manor NY 10510

http://electrooptical.net
http://hobbs-eo.com

[toc] | [prev] | [next] | [standalone]

#29807

torsdag den 9. juli 2020 kl. 21.31.10 UTC+2 skrev Phil Hobbs:
> On 2020-07-09 14:37, Rick C wrote:
> > On Thursday, July 9, 2020 at 4:25:32 AM UTC-4, Phil Hobbs wrote:
> >> On 2020-07-08 10:19, Rick C wrote:
> >>> On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote:
> >>>> On 2020-07-08 Rick C wrote in comp.arch.embedded:
> >>>>> Wow!  Designing in a group is strange.  I'm helping with the 
> >>>>> design of a ventilator and it is a unique experience.  We
> >>>>> have people of many skill levels and talents, many I don't
> >>>>> even know.
> >>>> 
> >>>> That is the good part of designing with a group. You can have
> >>>> many more talents and skills than can be combined in a single
> >>>> person. For a medical product like this you need medical,
> >>>> software, hardware, mechanical and lots more skills. Not
> >>>> something that can be found in one person very often.
> >>>> 
> >>>> <snip, some project frustrations etc.>
> >>>> 
> >>>>> I literally have no idea how they are ever going to get this 
> >>>>> thing past any sort of approval process.  No one working on
> >>>>> the project even seems to understand what is required.
> >>>>> 
> >>>> 
> >>>> This is very worrying. As David already explained,
> >>>> documentation and approval is a very large part of medical
> >>>> device development. There is this famous Boeing quote about the
> >>>> weight of the paperwork required for a plane. I think you can
> >>>> extend this to medical devices as well.
> >>>> 
> >>>> Did they at least have a look at some standards that apply to 
> >>>> ventilators to check what will be required? I would start off
> >>>> with IEC 60601-1, IEC 62304 and ISO 80601-2-12, make sure you
> >>>> use the latest versions. But there will be more.
> >>>> 
> >>>> And this should have been done before the first schematic was
> >>>> drawn or line of code was written. Some standards put
> >>>> requirements on the development process and you can not comply
> >>>> with those if you start your certification efforts after the
> >>>> development is completed.
> >>>> 
> >>>> 
> >>>>> I guess I'm a bit frustrated by the lack of organization.
> >>>>> I'd like to step away, but the person acting as a leader
> >>>>> seems to want me in the group.
> >>>>> 
> >>>>> There is some work of my own I should do, so maybe I'll
> >>>>> stick around to get to rev 2 of the board and then step out.
> >>>>> 
> >>>> 
> >>>> If there has indeed been done nothing on the certification
> >>>> side, my feeling would be to step away as well.
> >>>> 
> >>>> 
> >>>>> I guess I'm used to working on my own.
> >>>>> 
> >>>> 
> >>>> Yes, than all is in your own hands. ;-)
> >>>> 
> >>>> But the advantage of a team is that you can concentrate on what
> >>>> you are good at and let others do what they are good at. And if
> >>>> the team is diverse and skilled enough (and properly led) the
> >>>> end result will be better that that of a single developer.
> >>>> 
> >>>> And I think a lot of medical device stuff can not be done by a 
> >>>> single person. There are many cases where you need an (expert) 
> >>>> reviewer in the process. Reviewing your own work is less than 
> >>>> optimal. ;-)
> >>> 
> >>> It seems the UK has an abbreviated set of requirements for
> >>> response to COVID-19 and that is what they are mostly working
> >>> with.  I forget the name of it.
> >>> 
> >>> They do get advice from time to time from professionals in the
> >>> field. My main concern is a direction they are currently going in
> >>> where more and more valves, pressure relief, etc. is being added
> >>> to the tubing right at the patient.  I'm not sure how it all will
> >>> be held in place. That and how they plan to get this through the
> >>> approval process.
> >>> 
> >>> I had a friend who worked on medical devices for a while before 
> >>> getting out.  He said they required that you "prove" your design
> >>> will not hurt the patient in any way.  Hard to do with a
> >>> ventilator.
> >> 
> >> IANAL, but the liability implications of that would be interfering
> >> with my sleep.
> > 
> > I guess you don't sleep well very often.  There will be no liability
> > issues.  This group is not going to produce the machines.  They will
> > hand the design off to a manufacturer who will produce, market and
> > obtain approvals for the machine.  Liability will be all theirs.
> > 
> > Most likely the machine will be totally redesigned anyway for cost
> > reduction and to obtain approvals.  As a group this is not a highly
> > knowledgeable design group.  I can't imagine this design will fly
> > without rework.
> > 
> 
> Okay, so they aren't actually doing anything productive. That does tend 
> to limit product liability. ;)
> 

I guess they just like to feel they are doing "something"

https://en.wikipedia.org/wiki/Displacement_(psychology)

[toc] | [prev] | [next] | [standalone]

#29811

On Thursday, July 9, 2020 at 6:36:33 PM UTC-4, lasselangwad...@gmail.com wrote:
> torsdag den 9. juli 2020 kl. 21.31.10 UTC+2 skrev Phil Hobbs:
> > On 2020-07-09 14:37, Rick C wrote:
> > > On Thursday, July 9, 2020 at 4:25:32 AM UTC-4, Phil Hobbs wrote:
> > >> On 2020-07-08 10:19, Rick C wrote:
> > >>> On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote:
> > >>>> On 2020-07-08 Rick C wrote in comp.arch.embedded:
> > >>>>> Wow!  Designing in a group is strange.  I'm helping with the 
> > >>>>> design of a ventilator and it is a unique experience.  We
> > >>>>> have people of many skill levels and talents, many I don't
> > >>>>> even know.
> > >>>> 
> > >>>> That is the good part of designing with a group. You can have
> > >>>> many more talents and skills than can be combined in a single
> > >>>> person. For a medical product like this you need medical,
> > >>>> software, hardware, mechanical and lots more skills. Not
> > >>>> something that can be found in one person very often.
> > >>>> 
> > >>>> <snip, some project frustrations etc.>
> > >>>> 
> > >>>>> I literally have no idea how they are ever going to get this 
> > >>>>> thing past any sort of approval process.  No one working on
> > >>>>> the project even seems to understand what is required.
> > >>>>> 
> > >>>> 
> > >>>> This is very worrying. As David already explained,
> > >>>> documentation and approval is a very large part of medical
> > >>>> device development. There is this famous Boeing quote about the
> > >>>> weight of the paperwork required for a plane. I think you can
> > >>>> extend this to medical devices as well.
> > >>>> 
> > >>>> Did they at least have a look at some standards that apply to 
> > >>>> ventilators to check what will be required? I would start off
> > >>>> with IEC 60601-1, IEC 62304 and ISO 80601-2-12, make sure you
> > >>>> use the latest versions. But there will be more.
> > >>>> 
> > >>>> And this should have been done before the first schematic was
> > >>>> drawn or line of code was written. Some standards put
> > >>>> requirements on the development process and you can not comply
> > >>>> with those if you start your certification efforts after the
> > >>>> development is completed.
> > >>>> 
> > >>>> 
> > >>>>> I guess I'm a bit frustrated by the lack of organization.
> > >>>>> I'd like to step away, but the person acting as a leader
> > >>>>> seems to want me in the group.
> > >>>>> 
> > >>>>> There is some work of my own I should do, so maybe I'll
> > >>>>> stick around to get to rev 2 of the board and then step out.
> > >>>>> 
> > >>>> 
> > >>>> If there has indeed been done nothing on the certification
> > >>>> side, my feeling would be to step away as well.
> > >>>> 
> > >>>> 
> > >>>>> I guess I'm used to working on my own.
> > >>>>> 
> > >>>> 
> > >>>> Yes, than all is in your own hands. ;-)
> > >>>> 
> > >>>> But the advantage of a team is that you can concentrate on what
> > >>>> you are good at and let others do what they are good at. And if
> > >>>> the team is diverse and skilled enough (and properly led) the
> > >>>> end result will be better that that of a single developer.
> > >>>> 
> > >>>> And I think a lot of medical device stuff can not be done by a 
> > >>>> single person. There are many cases where you need an (expert) 
> > >>>> reviewer in the process. Reviewing your own work is less than 
> > >>>> optimal. ;-)
> > >>> 
> > >>> It seems the UK has an abbreviated set of requirements for
> > >>> response to COVID-19 and that is what they are mostly working
> > >>> with.  I forget the name of it.
> > >>> 
> > >>> They do get advice from time to time from professionals in the
> > >>> field. My main concern is a direction they are currently going in
> > >>> where more and more valves, pressure relief, etc. is being added
> > >>> to the tubing right at the patient.  I'm not sure how it all will
> > >>> be held in place. That and how they plan to get this through the
> > >>> approval process.
> > >>> 
> > >>> I had a friend who worked on medical devices for a while before 
> > >>> getting out.  He said they required that you "prove" your design
> > >>> will not hurt the patient in any way.  Hard to do with a
> > >>> ventilator.
> > >> 
> > >> IANAL, but the liability implications of that would be interfering
> > >> with my sleep.
> > > 
> > > I guess you don't sleep well very often.  There will be no liability
> > > issues.  This group is not going to produce the machines.  They will
> > > hand the design off to a manufacturer who will produce, market and
> > > obtain approvals for the machine.  Liability will be all theirs.
> > > 
> > > Most likely the machine will be totally redesigned anyway for cost
> > > reduction and to obtain approvals.  As a group this is not a highly
> > > knowledgeable design group.  I can't imagine this design will fly
> > > without rework.
> > > 
> > 
> > Okay, so they aren't actually doing anything productive. That does tend 
> > to limit product liability. ;)
> > 
> 
> I guess they just like to feel they are doing "something"
> 
> https://en.wikipedia.org/wiki/Displacement_(psychology)

They are doing something.  Redesign does not mean starting over.  Every time a second rev of a design is produced it is a redesign.  

What will be interesting is if they can get a working design that can work in all modes of operation.  Most projects don't even attempt that.  That will be a design worth reworking to meet approvals.  

There seem to be lot more replies to this thread as soon as an opportunity to offer something negative was presented.  That says a lot about this group I would say... or maybe just people in general.  

I was starting to think I was posting in s.e.d.

-- 

  Rick C.

  --+ Get 1,000 miles of free Supercharging
  --+ Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#29819

On 10/7/20 11:36 am, Rick C wrote:
> On Thursday, July 9, 2020 at 6:36:33 PM UTC-4, lasselangwad...@gmail.com wrote:
>> torsdag den 9. juli 2020 kl. 21.31.10 UTC+2 skrev Phil Hobbs:
>>> On 2020-07-09 14:37, Rick C wrote:
>>>> On Thursday, July 9, 2020 at 4:25:32 AM UTC-4, Phil Hobbs wrote:
>>>>> On 2020-07-08 10:19, Rick C wrote:
>>>>>> On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote:
>>>>>>> On 2020-07-08 Rick C wrote in comp.arch.embedded:
>>>>>>>> Wow!  Designing in a group is strange.  I'm helping with the
>>>>>>>> design of a ventilator and it is a unique experience.  We
>>>>>>>> have people of many skill levels and talents, many I don't
>>>>>>>> even know.
>>>>>>>
>>>>>>> That is the good part of designing with a group. You can have
>>>>>>> many more talents and skills than can be combined in a single
>>>>>>> person. For a medical product like this you need medical,
>>>>>>> software, hardware, mechanical and lots more skills. Not
>>>>>>> something that can be found in one person very often.
>>>>>>>
>>>>>>> <snip, some project frustrations etc.>
>>>>>>>
>>>>>>>> I literally have no idea how they are ever going to get this
>>>>>>>> thing past any sort of approval process.  No one working on
>>>>>>>> the project even seems to understand what is required.
>>>>>>>>
>>>>>>>
>>>>>>> This is very worrying. As David already explained,
>>>>>>> documentation and approval is a very large part of medical
>>>>>>> device development. There is this famous Boeing quote about the
>>>>>>> weight of the paperwork required for a plane. I think you can
>>>>>>> extend this to medical devices as well.
>>>>>>>
>>>>>>> Did they at least have a look at some standards that apply to
>>>>>>> ventilators to check what will be required? I would start off
>>>>>>> with IEC 60601-1, IEC 62304 and ISO 80601-2-12, make sure you
>>>>>>> use the latest versions. But there will be more.
>>>>>>>
>>>>>>> And this should have been done before the first schematic was
>>>>>>> drawn or line of code was written. Some standards put
>>>>>>> requirements on the development process and you can not comply
>>>>>>> with those if you start your certification efforts after the
>>>>>>> development is completed.
>>>>>>>
>>>>>>>
>>>>>>>> I guess I'm a bit frustrated by the lack of organization.
>>>>>>>> I'd like to step away, but the person acting as a leader
>>>>>>>> seems to want me in the group.
>>>>>>>>
>>>>>>>> There is some work of my own I should do, so maybe I'll
>>>>>>>> stick around to get to rev 2 of the board and then step out.
>>>>>>>>
>>>>>>>
>>>>>>> If there has indeed been done nothing on the certification
>>>>>>> side, my feeling would be to step away as well.
>>>>>>>
>>>>>>>
>>>>>>>> I guess I'm used to working on my own.
>>>>>>>>
>>>>>>>
>>>>>>> Yes, than all is in your own hands. ;-)
>>>>>>>
>>>>>>> But the advantage of a team is that you can concentrate on what
>>>>>>> you are good at and let others do what they are good at. And if
>>>>>>> the team is diverse and skilled enough (and properly led) the
>>>>>>> end result will be better that that of a single developer.
>>>>>>>
>>>>>>> And I think a lot of medical device stuff can not be done by a
>>>>>>> single person. There are many cases where you need an (expert)
>>>>>>> reviewer in the process. Reviewing your own work is less than
>>>>>>> optimal. ;-)
>>>>>>
>>>>>> It seems the UK has an abbreviated set of requirements for
>>>>>> response to COVID-19 and that is what they are mostly working
>>>>>> with.  I forget the name of it.
>>>>>>
>>>>>> They do get advice from time to time from professionals in the
>>>>>> field. My main concern is a direction they are currently going in
>>>>>> where more and more valves, pressure relief, etc. is being added
>>>>>> to the tubing right at the patient.  I'm not sure how it all will
>>>>>> be held in place. That and how they plan to get this through the
>>>>>> approval process.
>>>>>>
>>>>>> I had a friend who worked on medical devices for a while before
>>>>>> getting out.  He said they required that you "prove" your design
>>>>>> will not hurt the patient in any way.  Hard to do with a
>>>>>> ventilator.
>>>>>
>>>>> IANAL, but the liability implications of that would be interfering
>>>>> with my sleep.
>>>>
>>>> I guess you don't sleep well very often.  There will be no liability
>>>> issues.  This group is not going to produce the machines.  They will
>>>> hand the design off to a manufacturer who will produce, market and
>>>> obtain approvals for the machine.  Liability will be all theirs.
>>>>
>>>> Most likely the machine will be totally redesigned anyway for cost
>>>> reduction and to obtain approvals.  As a group this is not a highly
>>>> knowledgeable design group.  I can't imagine this design will fly
>>>> without rework.
>>>>
>>>
>>> Okay, so they aren't actually doing anything productive. That does tend
>>> to limit product liability. ;)
>>>
>>
>> I guess they just like to feel they are doing "something"
>>
>> https://en.wikipedia.org/wiki/Displacement_(psychology)
> 
> They are doing something.

But not something that will be useful to anyone who actually needs a 
ventilator.

The entire design of the Puritan Bennett 560 current-model approved 
ventilator from Medtronic was released under a permissive license way 
back in March. Why does your group think they can (or should?) do better.

> There seem to be lot more replies to this thread as soon as an opportunity to offer something negative was presented.

You get criticism most of the because you spend most of your time 
prevaricating. Change your default mode of response to match that of any 
vaguely reasonable person and you'll find discussion much more productive.

CH

[toc] | [prev] | [next] | [standalone]

#29821

On Friday, July 10, 2020 at 2:17:22 AM UTC-4, Clifford Heath wrote:
> On 10/7/20 11:36 am, Rick C wrote:
> > 
> > They are doing something.
> 
> But not something that will be useful to anyone who actually needs a 
> ventilator.

Sorry, that's just your BS.  Nothing to reply to. 


> The entire design of the Puritan Bennett 560 current-model approved 
> ventilator from Medtronic was released under a permissive license way 
> back in March. Why does your group think they can (or should?) do better.

Yes, I've looked at that design and it is very complex and uses a EOL CPU.  They have a sensing circuit to detect power going to the piezo sounder.  Not sure that sort of robustness is required.


> > There seem to be lot more replies to this thread as soon as an opportunity to offer something negative was presented.
> 
> You get criticism most of the because you spend most of your time 
> prevaricating. Change your default mode of response to match that of any 
> vaguely reasonable person and you'll find discussion much more productive.

Thank you for your input.  I look forward to your next reply.  Oh, and please trim your posts. 

-- 

  Rick C.

  +-- Get 1,000 miles of free Supercharging
  +-- Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#29828

On 2020-07-10 Rick C wrote in comp.arch.embedded:
> On Friday, July 10, 2020 at 2:17:22 AM UTC-4, Clifford Heath wrote:
>
>> The entire design of the Puritan Bennett 560 current-model approved 
>> ventilator from Medtronic was released under a permissive license way 
>> back in March. Why does your group think they can (or should?) do better.
>
> Yes, I've looked at that design and it is very complex and uses a EOL CPU.  They have a sensing circuit to detect power going to the piezo sounder.  Not sure that sort of robustness is required.

This sensing circuit is most probably a risk control that has been
implemented as the result of a design risk analysis. The sounder is
probably used for a medical alarm, which puts a lot of requirements on
performance of the sounder circuit.

You can only be sure that sort of robustness is desired if you perform a
design risk analysis.


-- 
Stef    (remove caps, dashes and .invalid from e-mail address to reply by mail)

Riffle West Virginia is so small that the Boy Scout had to double as the
town drunk.

[toc] | [prev] | [next] | [standalone]

#29796

On 08/07/2020 16:19, Rick C wrote:
> On Wednesday, July 8, 2020 at 8:14:05 AM UTC-4, Stef wrote:
>> On 2020-07-08 Rick C wrote in comp.arch.embedded:
>>> Wow!  Designing in a group is strange.  I'm helping with the
>>> design of a ventilator and it is a unique experience.  We have
>>> people of many skill levels and talents, many I don't even know.
>> 
>> That is the good part of designing with a group. You can have many
>> more talents and skills than can be combined in a single person.
>> For a medical product like this you need medical, software,
>> hardware, mechanical and lots more skills. Not something that can
>> be found in one person very often.
>> 
>> <snip, some project frustrations etc.>
>> 
>>> I literally have no idea how they are ever going to get this
>>> thing past any sort of approval process.  No one working on the
>>> project even seems to understand what is required.
>>> 
>> 
>> This is very worrying. As David already explained, documentation
>> and approval is a very large part of medical device development.
>> There is this famous Boeing quote about the weight of the paperwork
>> required for a plane. I think you can extend this to medical
>> devices as well.
>> 
>> Did they at least have a look at some standards that apply to
>> ventilators to check what will be required? I would start off with
>> IEC 60601-1, IEC 62304 and ISO 80601-2-12, make sure you use the
>> latest versions. But there will be more.
>> 
>> And this should have been done before the first schematic was drawn
>> or line of code was written. Some standards put requirements on the
>> development process and you can not comply with those if you start
>> your certification efforts after the development is completed.
>> 
>> 
>>> I guess I'm a bit frustrated by the lack of organization.  I'd
>>> like to step away, but the person acting as a leader seems to
>>> want me in the group.
>>> 
>>> There is some work of my own I should do, so maybe I'll stick
>>> around to get to rev 2 of the board and then step out.
>>> 
>> 
>> If there has indeed been done nothing on the certification side, my
>> feeling would be to step away as well.
>> 
>> 
>>> I guess I'm used to working on my own.
>>> 
>> 
>> Yes, than all is in your own hands. ;-)
>> 
>> But the advantage of a team is that you can concentrate on what you
>> are good at and let others do what they are good at. And if the
>> team is diverse and skilled enough (and properly led) the end
>> result will be better that that of a single developer.
>> 
>> And I think a lot of medical device stuff can not be done by a
>> single person. There are many cases where you need an (expert)
>> reviewer in the process. Reviewing your own work is less than
>> optimal. ;-)
> 
> It seems the UK has an abbreviated set of requirements for response
> to COVID-19 and that is what they are mostly working with.  I forget
> the name of it.
> 
> They do get advice from time to time from professionals in the field.
> My main concern is a direction they are currently going in where more
> and more valves, pressure relief, etc. is being added to the tubing
> right at the patient.  I'm not sure how it all will be held in place.
> That and how they plan to get this through the approval process.
> 
> I had a friend who worked on medical devices for a while before
> getting out.  He said they required that you "prove" your design will
> not hurt the patient in any way.  Hard to do with a ventilator.

I have worked on the side-lines of a few medical-related devices.  The
requirements and approval process is hard.  On a board I worked with,
the prime function - the top priority function that must not fail - was
to turn off all outputs and make sure it did not interfere with manual
use of the system when auto mode was not enabled.  Running the motor was
a secondary function that could be done if enabled and all is well, but
having everything off was still classified as "working correctly".  It's
a weird way to think about things.

> 
> I don't mind working on the team.  It's seeing them go in odd
> directions that bugs me.  This thing will probably cost hundreds of
> dollars in the final BOM without anything like profit or overhead
> added in.  People were arguing against adding $0.10 for more pins on
> a processor.  Then later they decided to not only go with the larger
> pin count, but bump from an 8 bit AVR to an ARM CM4F adding several
> dollars.  That sort of inconsistency drives me nuts.  "Every dollar
> counts!"  Yes it does, so you need to justify the cost *rationally*.
> 
> 

[toc] | [prev] | [next] | [standalone]

#29797

On 7/7/2020 6:46 PM, Rick C wrote:
> Wow!  Designing in a group is strange.  I'm helping with the design of a ventilator and it is a unique experience.  We have people of many skill levels and talents, many I don't even know.  The design seems to ping pong around based on the hot button issue of the day.  They already have someone to do board level design, but he has a day job, so the work gets done a bit helter skelter.  I mostly try to identify potential bugs.
> 
> Most of the people are in the UK with a couple in the EU.  I'm in the US along with one other person.
> 
> We have semiweekly meetings on zoom or other sites.  There is no strong organization.
> 
> I'm surprised as much is getting done as it has been.  The original design used an Arduino and once the lack of I/Os became a hindrance we are switching to an ARM, but nothing remotely like a proper spec was generated and the processor initially picked is now out of pins.  The first rev of the main board has many issues including the isolation of the heat sink tabs by thermal relief connections.
> 
> I literally have no idea how they are ever going to get this thing past any sort of approval process.  No one working on the project even seems to understand what is required.
> 
> I guess I'm a bit frustrated by the lack of organization.  I'd like to step away, but the person acting as a leader seems to want me in the group.
> 
> There is some work of my own I should do, so maybe I'll stick around to get to rev 2 of the board and then step out.
> 
> I guess I'm used to working on my own.
> 

That all sounds frustrating. For sale to the US, you'll need to satisfy 
some specific FDA requirements and be prepared to prove it, including 
dotting Is/crossing Ts in just the right way. You have an international 
crew so you'll probably have to satisfy certain other international 
requirements. I'd float the idea of getting an FDA expert on your team 
as soon as possible. You'll need that kind of talent, otherwise your 
efforts will be wasted.

JJS

[toc] | [prev] | [next] | [standalone]

#29810

On 7/7/2020 6:46 PM, Rick C wrote:
> Wow!  Designing in a group is strange.  I'm helping with the design of a
> ventilator and it is a unique experience.  We have people of many skill
> levels and talents, many I don't even know.

The downside of groups is folks tend to have narrow "specialties"
and there often are not "generalists" who can look at the entire
project and see where (function) responsibilities could better
be shifted.

(I worked on a 30-man project where one developer designed a ~80 sq in
PCB populated entirely with DIP switches -- cuz it didn't occur to him
that the processor could make those settings more economically and in
a more user-friendly manner than he -- with no MCU experience -- had
ever considered)

> We have semiweekly meetings on zoom or other sites.  There is no strong
> organization.
> 
> I'm surprised as much is getting done as it has been.  The original design
> used an Arduino and once the lack of I/Os became a hindrance we are
> switching to an ARM, but nothing remotely like a proper spec was generated
> and the processor initially picked is now out of pins.  The first rev of the
> main board has many issues including the isolation of the heat sink tabs by
> thermal relief connections.
> 
> I literally have no idea how they are ever going to get this thing past any
> sort of approval process.  No one working on the project even seems to
> understand what is required.

If the goal is just to develop a proof-of-principle prototype *or*
to develop something for second/third world markets, this MIGHT work.
But, in the US (and I imagine similarly in the EU), there is a strong
emphasis on PROCESS... not just "results".  How does anyone know
that it will ALWAYS work??  And, under which conditions it won't?

A continuous ventilator is probably a Class II device.  (Class III
being the most stringent requirements)

cGMPs tend to center around having a thorough (documented!) process
and good papertrail to show that you took the effort "seriously".  If
you don't have a written spec BEFORE you start the design, how do you
know WHAT you are designing ("Did you make this up, as you went?")?
And, how can you evaluate whether or not you have met your design goals?

What tests did you run?  What were the results?  What did you do to
remedy substandard behaviors?  Did these efforts achieve the desired
result (did you even BOTHER to rerun the tests after those changes?)

There is no one at the FDA who is going to evaluate your schematics,
check your code for errors or even check that your device does what it
claims to do!  They typically don't have the resources nor expertise to
do so.  *You* make those assertions and convince them of your sincerity
and diligence with your papertrail/process (and reputation).

[And, of course, expose yourself to future litigation if things
go tits up!]

Bottom line, any manufacturer who would consider producing the device
would want the same sort of assurances (from you) that the FDA wants as
they would be putting THEIR reputation (and assets) on the line.  They're
likely NOT going to opt for an "Arduino" as a key component unless
they have some assurances that the module will remain available for
a considerable amount of time AND won't change (i.e., no firmware
upgrades as they'd require the product to be revalidated)

OTOH, if you're trying to *hack* together something for disadvantaged
third-world countries (pandemic or otherwise), they'll likely be
grateful for whatever they can get their hands on.  And, you'll likely
want to use components that can be easily acquired instead of
requiring some significant design or purchasing investment.

[toc] | [prev] | [next] | [standalone]

#29814

On Thursday, July 9, 2020 at 9:34:04 PM UTC-4, Don Y wrote:
> On 7/7/2020 6:46 PM, Rick C wrote:
> > Wow!  Designing in a group is strange.  I'm helping with the design of a
> > ventilator and it is a unique experience.  We have people of many skill
> > levels and talents, many I don't even know.
> 
> The downside of groups is folks tend to have narrow "specialties"
> and there often are not "generalists" who can look at the entire
> project and see where (function) responsibilities could better
> be shifted.
> 
> (I worked on a 30-man project where one developer designed a ~80 sq in
> PCB populated entirely with DIP switches -- cuz it didn't occur to him
> that the processor could make those settings more economically and in
> a more user-friendly manner than he -- with no MCU experience -- had
> ever considered)

How can a design group operate with so little communication that this could happen??? 


> > We have semiweekly meetings on zoom or other sites.  There is no strong
> > organization.
> > 
> > I'm surprised as much is getting done as it has been.  The original design
> > used an Arduino and once the lack of I/Os became a hindrance we are
> > switching to an ARM, but nothing remotely like a proper spec was generated
> > and the processor initially picked is now out of pins.  The first rev of the
> > main board has many issues including the isolation of the heat sink tabs by
> > thermal relief connections.
> > 
> > I literally have no idea how they are ever going to get this thing past any
> > sort of approval process.  No one working on the project even seems to
> > understand what is required.
> 
> If the goal is just to develop a proof-of-principle prototype *or*
> to develop something for second/third world markets, this MIGHT work.
> But, in the US (and I imagine similarly in the EU), there is a strong
> emphasis on PROCESS... not just "results".  How does anyone know
> that it will ALWAYS work??  And, under which conditions it won't?
> 
> A continuous ventilator is probably a Class II device.  (Class III
> being the most stringent requirements)
> 
> cGMPs tend to center around having a thorough (documented!) process
> and good papertrail to show that you took the effort "seriously".  If
> you don't have a written spec BEFORE you start the design, how do you
> know WHAT you are designing ("Did you make this up, as you went?")?
> And, how can you evaluate whether or not you have met your design goals?

Yes, I have tried to get a spec done for selection a new processor (without doing it all myself), but the inputs were thin.  The one software developer started talking about how much better the tools are with ST micros and tossing part numbers out so that is what was picked. 

Much is being made up as we go along.  When it was decided to go with I believe it is called "assisted" mode ventilation, that puts a whole different set of requirements on the system including the plumbing and the main circuit board.  

If a design is produced that works, and can be shown to work by the methods required, why would the lack of documentation of the process be a stumbling block? 

> What tests did you run?  What were the results?  What did you do to
> remedy substandard behaviors?  Did these efforts achieve the desired
> result (did you even BOTHER to rerun the tests after those changes?)

Not sure what you are getting at here.  The tests must be met by a finished unit. 


> There is no one at the FDA who is going to evaluate your schematics,
> check your code for errors or even check that your device does what it
> claims to do!  They typically don't have the resources nor expertise to
> do so.  *You* make those assertions and convince them of your sincerity
> and diligence with your papertrail/process (and reputation).

That seems like even more work than any other method of verification.  In DOD it's all about passing the acceptance test.  Of course there are requirements on the process, but that is mostly about developing the requirements and tests. 


> [And, of course, expose yourself to future litigation if things
> go tits up!]
> 
> Bottom line, any manufacturer who would consider producing the device
> would want the same sort of assurances (from you) 

No, not from us.  That is ally their baby. 


> that the FDA wants as
> they would be putting THEIR reputation (and assets) on the line.  They're
> likely NOT going to opt for an "Arduino" as a key component unless
> they have some assurances that the module will remain available for
> a considerable amount of time AND won't change (i.e., no firmware
> upgrades as they'd require the product to be revalidated)

Not THE Arduino, the processor and basic design.  The Arduino really is nothing more than a power supply and a processor with a crystal.  I think there is a USB debugger chip.  


> OTOH, if you're trying to *hack* together something for disadvantaged
> third-world countries (pandemic or otherwise), they'll likely be
> grateful for whatever they can get their hands on.  And, you'll likely
> want to use components that can be easily acquired instead of
> requiring some significant design or purchasing investment.

Yeah, that was one of the goals, but the case is a custom design of stainless steel sheet metal and a custom plastic overlay for the front panel.  Of course the main board is a custom design and there are components used that will be sole sourced... the O2 sensor, the pressure sensors, the gear motor.  I think there are some plexiglass pieces for pressing on the bag and that will be one design since variations may well cause changes in how the pressure varies with force from the motor, volume, etc.  Then there will be specific parts indicated for the external plumbing.  So while anyone can build one, it won't be a simple matter of going to the hardware store to get the parts. 

One of the trickier parts is the air flow sensor.  They are measuring the differential pressure across an orifice.  Most of the use will be at the low end where the response is not linear and sensitivity is not good.  I found they are using a commercial product to calibrate their 3D printed device.  Why not just buy the commercial device, the look almost the same.  The 3D printed device has a socket for the O2 sensor...  

-- 

  Rick C.

  -+- Get 1,000 miles of free Supercharging
  -+- Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#29815

On 7/9/2020 7:01 PM, Rick C wrote:
> On Thursday, July 9, 2020 at 9:34:04 PM UTC-4, Don Y wrote:
>> On 7/7/2020 6:46 PM, Rick C wrote:
>> The downside of groups is folks tend to have narrow "specialties" and
>> there often are not "generalists" who can look at the entire project and
>> see where (function) responsibilities could better be shifted.
>> 
>> (I worked on a 30-man project where one developer designed a ~80 sq in PCB
>> populated entirely with DIP switches -- cuz it didn't occur to him that
>> the processor could make those settings more economically and in a more
>> user-friendly manner than he -- with no MCU experience -- had ever
>> considered)
> 
> How can a design group operate with so little communication that this could
> happen???

Who *should* take responsibility for that sort of decision, other than
the Project Manager?  Should his competencies include ALL of the areas
of expertise for the team?  Should each team member question the
requirements imposed on himself by other team members' aspects of the
project?

You start off with the assumption that folks are (nominally) competent.
If you question each assertion/demand, then you spend all of your time
asking "Why" instead of assuming that there is a Good Reason "why"
and, other than your own insecurity or curiosity, there's no need for
you to KNOW all of those details ("Why is the machine painted beige?
Why are we using steel instead of aluminum?  Why HiNIL instead of CMOS?
Why Motogorilla instead of Intel?")

Most folks don't have much experience outside of their own narrow field
of expertise.  So, it doesn't dawn on them that the design constraints
COULD be different.

I designed a CPU many years ago.  My best friend was writing the code to
execute on it.  When we installed the code on the prototype processor,
NOTHING worked!  We were each infinitely confident in the OTHER'S abilities
so immediately assumed the mistake lie in our own efforts.  Eventually,
we each realized there were no errors that we could identify in our own
efforts.  So, started looking at each other.  It turned out, my friend
(being a software person) instinctively thought in terms of "bytes".
I, in a hardware role, had designed the processor to operate on WORDS
(it was not possible to address individual bytes).  So, all of the
addresses in his code were off by a factor of two!

"Didn't you think it unusual that ALL of your address fields were EVEN??"

Neither of us had even considered this would be something that we'd have
to agree upon; it was "obvious" to both of us, individually -- just not
the same assumptions!  :<

The (hardware) guy designing the DIP switch board knew that he had to
have a bunch of user-specified parameters for his circuit to operate.
So, he relied on the "usual" means of getting parameters into a
hardware circuit:  switches/jumpers/etc.  Because no one was actively
overseeing his design ("trust the designer"), it never occurred to
anyone (other than me) to suggest "there's a better way!"

But, I was only involved because of my own personal curiosity as to
what his circuit did and how it did it.  The project manager (a MechE)
was completely clueless...

>> cGMPs tend to center around having a thorough (documented!) process and
>> good papertrail to show that you took the effort "seriously".  If you
>> don't have a written spec BEFORE you start the design, how do you know
>> WHAT you are designing ("Did you make this up, as you went?")? And, how
>> can you evaluate whether or not you have met your design goals?
> 
> Yes, I have tried to get a spec done for selection a new processor (without
> doing it all myself), but the inputs were thin.  The one software developer
> started talking about how much better the tools are with ST micros and
> tossing part numbers out so that is what was picked.

Regulatory agencies don't care that he "picked" an ST device instead of
a GI device.  What they want to see is that there was a formal specification
of what was needed and a VERIFICATION that the chosen device met those
requirements.

You can implement a multiplication operator many different ways.  The
regulators don't care WHICH way you choose -- just that the chosen
way satisfies the stated requirements.

> Much is being made up as we go along.  When it was decided to go with I
> believe it is called "assisted" mode ventilation, that puts a whole
> different set of requirements on the system including the plumbing and the
> main circuit board.
> 
> If a design is produced that works, and can be shown to work by the methods
> required, why would the lack of documentation of the process be a stumbling
> block?

FDA is all about process.

When you (personally) design something, I'd wager that you do lots of
testing WHILE putting the design together, evolving its requirements, etc.
Even if that testing is informal, shirt-sleeve sort of effort.  Why do
you do it?  Why not just wait until you're done and test "end-to-end"?
Ans:  the testing gives you increased confidence in the design at various
levels WITHIN the design.

I can design/implement an HVAC system and verify that it keeps the house
at 72 degrees, "exactly".  But, if I notice that the furnace is running
continuously and it's 71 degrees outside, I don't have much faith in that
design/implementation!  Is the furnace not generating the required amount
of heat?  Is the blower running too slowly?  Are there air leaks?  etc.

How confident (put a NUMBER on this!) would I be that it could maintain
that 72 degrees if it was 20 degrees outside?

How confident would you be that the ventilator would work against an
increased back pressure?  Or, at a lower desired flow rate/volume?
Or, with a "low mains" voltage?  Can you test EVERY possible operating
condition?

>> What tests did you run?  What were the results?  What did you do to remedy
>> substandard behaviors?  Did these efforts achieve the desired result (did
>> you even BOTHER to rerun the tests after those changes?)
> 
> Not sure what you are getting at here.  The tests must be met by a finished
> unit.

Testing occurs at two levels (at least -- a developer can always do his
own "experiments" off on the side).  There's an "inner loop" that consists
of "specify, design, implement, VERIFY" that can potentially be repeated
many times.  (but, each time it is a FORMAL process... an ENDORSED spec,
documented test suite, documented results, documented triage)  Each of
these iterations becomes part of the Design History File (DHF) -- a
written record of how you adhered to your process (which was FORMALLY
codified *before* you started all of this!).

Once you think you are "done", your design is formally VALIDATED.
This is when you prove that it meets the intended design goals/user
requirements.  If you fail the validation step, you reenter the above
iteration sequence until you think you're ready to try again.

VALIDATION is typically "expensive" (time/labor) so you don't want to
undertake it casually.  By contrast, VERIFICATION is largely an
internal effort that YOUR PROCESS has control over (who can perform
the activities, how they are controlled, logged, etc.).  So, its
less expensive than validation but more expensive than a lone
developer "tinkering" with some aspect of his design "off the books".

Once validated, the design and implementation are frozen.  You can't
replace multiply() with an "equivalent" version without requiring
revalidation.  You may THINK that all that matters is the "product"
produced by that routine but may discover (in a validation) that
there are unintended side-effects that compromise the design...
maybe the addresses of some routines/variables have been altered,
slightly (though "equivalently") and a bug has been uncovered
that was masked by the previous address bindings!  Or, maybe the
routine is faster and it exposes a race that had previously been
"biased" advantageously.

Remember, the product is not the *abstract* representation that
exists on your design documents (schematics, source code, etc.)
but, rather, the ACTUAL reification that "Manufacturing" churns
out the loading dock.  So, change the compiler switches and you
end up with a new binary --> revalidate!  Change the compiler
and you end up with a new binary --> revalidate!  Change the
processor (because it had an internal bug that has been fixed
in the latest mask) --> revalidate.

Or, engage in a *more* complex analysis that PROVES that the
change(s) have no impact on the design -- at all levels IN the design!

>> There is no one at the FDA who is going to evaluate your schematics, check
>> your code for errors or even check that your device does what it claims to
>> do!  They typically don't have the resources nor expertise to do so.
>> *You* make those assertions and convince them of your sincerity and
>> diligence with your papertrail/process (and reputation).
> 
> That seems like even more work than any other method of verification.  In
> DOD it's all about passing the acceptance test.  Of course there are
> requirements on the process, but that is mostly about developing the
> requirements and tests.

My experience with DoD has only been as a Manufacturing Engineer.  I
recall lots of "useless paperwork" (in the eyes of a teenager) that had
to document each change I made (even if it was obvious:  "The hole is
tapped for #6-32 and the parts list calls out a #4-40"), every
"defective" component that I replaced (along with SAVING the
actual component for later analysis), how I uncovered the fault,
how long it took to diagnose, repair, retest, etc.  None of these
activities make *this* unit operate better; but, they can be
insightful to folks (bean counters) behind the scenes revising
the design, preparing courseware, etc.

But, I can't imagine there isn't a similar set of controls over process,
behind the scenes.

>> [And, of course, expose yourself to future litigation if things go tits
>> up!]
>> 
>> Bottom line, any manufacturer who would consider producing the device 
>> would want the same sort of assurances (from you)
> 
> No, not from us.  That is ally their baby.

But THEY have to make these assurances to the regulators.

I've only dealt with one product that had *direct* exposure to patients
(all of the others were indirect -- diagnostic, etc.).  But, it was
a proof of concept design that was never intended to be manufactured
"as is".  Instead, we had to flesh out the design to show ONE WAY
that the desired functionality could be provided, "reliably".  The
commissioned goal was a "dog-and-pony" that executives/investors
could poke at to decide if it was a worthwhile product to develop
(that THEY would then take on with their armies of STAFF) as the
half-dozen of us had neither the resources (manufacturing) nor
desire (the IDEA is where all of the fun lies!) to undertake FOR
them.

So, we could employ all sorts of "undisciplined" design methodologies
to get to that point -- something that they couldn't do due to their
adherence to all of that formal structure.

I've worked on other projects where we made a very deliberate effort
to produce a product that was "a step away from manufacturing" (including
hundreds of kilobucks of machined stainless steel parts, custom designed
mechanisms, electronics, software, etc.) only to see the design scrapped
when brought to REAL production.  (when you try to make a REAL product,
instead of an approximation, you identify lots of little issues that
seriously impact manufacturability -- in that case, the mechanism was
incredibly elegant but would be hard to reliably produce in volume)

>> that the FDA wants as they would be putting THEIR reputation (and assets)
>> on the line.  They're likely NOT going to opt for an "Arduino" as a key
>> component unless they have some assurances that the module will remain
>> available for a considerable amount of time AND won't change (i.e., no
>> firmware upgrades as they'd require the product to be revalidated)
> 
> Not THE Arduino, the processor and basic design.  The Arduino really is
> nothing more than a power supply and a processor with a crystal.  I think
> there is a USB debugger chip.

No firmware onboard?  Toolchain never revised?  Libraries?  No mask
revisions in the processor?  Die shrinks?  Layout changes?

They are interested in making a product hobbyists/hardware-challenged
want to buy so are concerned with cost/profit and features.  They likely
don't expect any of their customers to complain because they trimmed
a clock cycle off of some particular opcode in the processor.  Or,
increased the amount of onboard RAM, or supported USB3, etc.

>> OTOH, if you're trying to *hack* together something for disadvantaged 
>> third-world countries (pandemic or otherwise), they'll likely be grateful
>> for whatever they can get their hands on.  And, you'll likely want to use
>> components that can be easily acquired instead of requiring some
>> significant design or purchasing investment.
> 
> Yeah, that was one of the goals, but the case is a custom design of
> stainless steel sheet metal and a custom plastic overlay for the front
> panel.  Of course the main board is a custom design and there are components
> used that will be sole sourced... the O2 sensor, the pressure sensors, the
> gear motor.  I think there are some plexiglass pieces for pressing on the
> bag and that will be one design since variations may well cause changes in
> how the pressure varies with force from the motor, volume, etc.  Then there
> will be specific parts indicated for the external plumbing.  So while anyone
> can build one, it won't be a simple matter of going to the hardware store to
> get the parts.

So, the idea that it's an "affordable" design suited for "less resourceful"
environments is no longer the case.

> One of the trickier parts is the air flow sensor.  They are measuring the
> differential pressure across an orifice.  Most of the use will be at the low
> end where the response is not linear and sensitivity is not good.  I found
> they are using a commercial product to calibrate their 3D printed device.
> Why not just buy the commercial device, the look almost the same.  The 3D
> printed device has a socket for the O2 sensor...

<shrug>  Despite their possible motivations, it really looks like this is
just a glorified hobbyist exercise -- being able to tell themselves they
are doing something "worthwhile" when, in fact, they are throwing away
their time/resources.

There was a group, here, that wanted to build "little houses" for The Homeless.
Lots of energy, excitement, press coverage, etc.  But, totally lacking in
the skills needed to actually BUILD little houses!  They'd have done more
good if they had flipped burgers at McDonald's for all the hours they
spent meeting and talking about it... and donated the monies to the
first homeless person they encountered on a street corner!

I think the idea of a low-cost, third-world ventilator would be admirable.
It's a "market" that doubtless won't be addressed (go where the money is!).
And, can likely avoid all of the effort/tedium/expense/legalese that selling
into first-world markets would entail.

It's also a much more challenging project!  Not just coming up with a
reproducible design but, also, looking past that to MAINTAINING the
design in environments that don't have easy access to the same sorts
of technology that we are accustomed to.  E.g., imagine every component,
individually, breaking.  How would you replace them if you were in
Sudan?  Yemen?  Ethiopia?  What do you do if you have a single "15A"
branch circuit powering an entire ward?  How many of these can you
support in addition to the other "required" equipment?  How will
your design fare if power fails/fluctuates often?  etc.

[I've had to "dumb down" designs, in the past, to ensure they could be
maintained in places hat are off-the-beaten-track.  It's really hard
to imagine how LITTLE you actually NEED when you are accustomed to having
more-than-enough!]

Good luck!

(BTW, if you're interested in the FDA issues in greater detail, chase
down Title 21 of the FDA's CFR 820.30 to get a general overview)

[toc] | [prev] | [next] | [standalone]

#29832

On Thu, 9 Jul 2020 19:01:28 -0700 (PDT), Rick C
<gnuarm.deletethisbit@gmail.com> wrote:

>On Thursday, July 9, 2020 at 9:34:04 PM UTC-4, Don Y wrote:
>
>> There is no one at the FDA who is going to evaluate your schematics,
>> check your code for errors or even check that your device does what it
>> claims to do!  They typically don't have the resources nor expertise to
>> do so.  *You* make those assertions and convince them of your sincerity
>> and diligence with your papertrail/process (and reputation).
>
>That seems like even more work than any other method of verification. 
>In DOD it's all about passing the acceptance test.  Of course there
>are requirements on the process, but that is mostly about developing
>the requirements and tests. 

In general the USFDA expects vendors to validate their own products.
They will presume that whatever it is works for its intended purpose
[else why bring it to them?] and, in my experience,they will be more
interested in documentation of trials proving effectiveness and in
production controls than in the details of designs or formulas, etc.


I worked on software for a diagnostic imaging system to render CT and
MRI volumes as holograms on film.  It was expected that - as with xray
- surgeons would rely on these films to plan interventions, but the
FDA examiners seemed less interested in image accuracy than in whether
developer fluid could leak from the automatic film processor.

Separately I worked on several machine vision QA/QC systems that were
used in pharmaceutical production: checking consistency of powders and
fluid mixtures, looking for tablets damaged in handling, checking that
packages were filled correctly, etc.  The FDA was concerned mainly
with consistency of our inspection results - correctness and/or
usefulness of our systems being left to the users (pharma companies)
to evaluate.


It's not easy to predict what examiners will focus on. YMMV.

George

[toc] | [prev] | [next] | [standalone]

#29842

On Friday, July 10, 2020 at 5:36:59 PM UTC-4, George Neuner wrote:
> On Thu, 9 Jul 2020 19:01:28 -0700 (PDT), Rick C
> <gnuarm.deletethisbit@gmail.com> wrote:
> 
> >On Thursday, July 9, 2020 at 9:34:04 PM UTC-4, Don Y wrote:
> >
> >> There is no one at the FDA who is going to evaluate your schematics,
> >> check your code for errors or even check that your device does what it
> >> claims to do!  They typically don't have the resources nor expertise to
> >> do so.  *You* make those assertions and convince them of your sincerity
> >> and diligence with your papertrail/process (and reputation).
> >
> >That seems like even more work than any other method of verification. 
> >In DOD it's all about passing the acceptance test.  Of course there
> >are requirements on the process, but that is mostly about developing
> >the requirements and tests. 
> 
> In general the USFDA expects vendors to validate their own products.
> They will presume that whatever it is works for its intended purpose
> [else why bring it to them?] and, in my experience,they will be more
> interested in documentation of trials proving effectiveness and in
> production controls than in the details of designs or formulas, etc.
> 
I was part of a CT manufacturing start up. what I learned is that
The key in FDA boils down to:
* Define your process.  (Say what you do to ensure quality)
* Build your design.    (do what you planned)
* V&V your design and process. (document all steps along the way)

It comes down to documentary evidence.

> 
> I worked on software for a diagnostic imaging system to render CT and
> MRI volumes as holograms on film.  It was expected that - as with xray
> - surgeons would rely on these films to plan interventions, but the
> FDA examiners seemed less interested in image accuracy than in whether
> developer fluid could leak from the automatic film processor.

You actually created film holograms from CT data?
Is there any published information about how you did that?

There are standard image quality tests you would perform and
report the results. If those passed, they would be pretty confident
in your imaging process and would focus on anything less well
documented.

> 
> Separately I worked on several machine vision QA/QC systems that were
> used in pharmaceutical production: checking consistency of powders and
> fluid mixtures, looking for tablets damaged in handling, checking that
> packages were filled correctly, etc.  The FDA was concerned mainly
> with consistency of our inspection results - correctness and/or
> usefulness of our systems being left to the users (pharma companies)
> to evaluate.
> 
> 
> It's not easy to predict what examiners will focus on. YMMV.
> 
> George

True. My experience is limited, so I'll leave it at that except:
Having worked on a product under FAA review recently,
I would say I prefer the FDA process much better.

HTH,
   Ed

[toc] | [prev] | [next] | [standalone]

#29845

On Tue, 14 Jul 2020 11:09:22 -0700 (PDT), Ed Prochak
<edprochak@gmail.com> wrote:

>On Friday, July 10, 2020 at 5:36:59 PM UTC-4, George Neuner wrote:
> 
>> I worked on software for a diagnostic imaging system to render CT and
>> MRI volumes as holograms on film.  It was expected that - as with xray
>> - surgeons would rely on these films to plan interventions, but the
>> FDA examiners seemed less interested in image accuracy than in whether
>> developer fluid could leak from the automatic film processor.
>
>You actually created film holograms from CT data?
>Is there any published information about how you did that?

I'm not aware of any:  I was a contractor on the project, implementing
a proprietary process.

I can say what was known publicly: that the process used multiple
"slice" exposures to create a master film, which then was used as an
exposure filter to create the final hologram films.  But I can't talk
about any processing that was done to prepare the volume imagery.


The process is owned by Holorad (http://holorad.com) and medical 
imaging systems are distributed by VOXEL (http://voxel.us).  There is
no technical information on their websites, but they may provide
something if you contact them.

George

[toc] | [prev] | [next] | [standalone]

#29816

There is presently a decision being made about various methods of detecting end of travel for the back stroke of the motor.  One of the selection criteria is "simplicity", 1 to 3.  I don't see that as an objective value, rather a subjective rating of what they think of each approach.  Cost is rated from 1 to 3 without any real consideration of a dollar (or pound) figure.  The three methods that use a detector each are rated 1 on cost (because there is some) and two methods are rated 3 on cost because they use timing (guessing) or motor current on reaching a mechanical stop.  

So do Hall effect sensors have any real issues such as magnetic interference?  They work off of a magnetic field, but not a rapidly varying field (the motor output is single digit RPM in use) so will local magnetic effects impact it, like the motor current?  The sensor will probably be 9 inches away.  Is a magnet built into Hall effect sensors or is that required to be added?  

Another choice is an optical sensor.  They list as a disadvantage optical interference!  That seems rather unlikely in a closed box especially.  There are openings, but not large.  For some reason this one is listed as poorest in simplicity.  Seems simple to me.  

They list circuit boards as being needed for those two and a micro switch.  I know these can be mounted on cables, but is there a reason why that would be a bad idea for reliability?  I recall in my very early days in engineering seeing front panels with switches and LEDs being wired up by hand via ribbon cable and heat shrink tubing.  That was equipment for a NASA ground station, forty years ago.  Likely they would not accept that now?  

There is also the option of the motor shaft encoder, but that is significantly more expensive and I recall there was a strong dislike of the $15 price.  I suggested they include a couple of the options in the circuit board and after development is done leave out the one you don't use.  They seem to think they can make all the decisions without knowing for sure how this will need to be designed. 

-- 

  Rick C.

  -++ Get 1,000 miles of free Supercharging
  -++ Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

#29823

On 7/9/2020 10:48 PM, Rick C wrote:
> There is presently a decision being made about various methods of detecting
> end of travel for the back stroke of the motor.  One of the selection
> criteria is "simplicity", 1 to 3.  I don't see that as an objective value,
> rather a subjective rating of what they think of each approach.  Cost is
> rated from 1 to 3 without any real consideration of a dollar (or pound)
> figure.  The three methods that use a detector each are rated 1 on cost
> (because there is some) and two methods are rated 3 on cost because they use
> timing (guessing) or motor current on reaching a mechanical stop.

A "binding" mechanism will fail to achieve its goal in a fixed period
of time AND will likely indicate a higher current draw, prematurely.
How *important* is that indication to the proper operation of the device?

How regularly do you expect the device to be maintained/serviced?
What sort of skill level do you expect from the parties doing that servicing?
(this goes to my previous comments re: third-world applications; first-world
likely have staff on-hand to maintain ALL of the kit that they utilize -- as
well as equipment suitable for those tasks)

> So do Hall effect sensors have any real issues such as magnetic
> interference?  They work off of a magnetic field, but not a rapidly varying
> field (the motor output is single digit RPM in use) so will local magnetic
> effects impact it, like the motor current?  The sensor will probably be 9
> inches away.  Is a magnet built into Hall effect sensors or is that required
> to be added?

Typically added if you're trying to monitor the presence of an
object (motor shaft) in a particular location.

> Another choice is an optical sensor.  They list as a disadvantage optical
> interference!  That seems rather unlikely in a closed box especially.  There
> are openings, but not large.  For some reason this one is listed as poorest
> in simplicity.  Seems simple to me.

What about dust/crud/*critters* interfering with the emitter (or detector)?

> They list circuit boards as being needed for those two and a micro switch.

You can put a HE sensor on the end of a cable.  Ditto for an optical sensor.
But, mounting to a PCB -- and affixing a cable to *that* -- may be easier
to manufacture/service (imagine having to reattach a pigtail to a bare
sensor)

> I know these can be mounted on cables, but is there a reason why that would
> be a bad idea for reliability?  I recall in my very early days in
> engineering seeing front panels with switches and LEDs being wired up by
> hand via ribbon cable and heat shrink tubing.  That was equipment for a NASA
> ground station, forty years ago.  Likely they would not accept that now?

Adding strain relief to a bare sensor becomes problematic.  A sensor mounted
on a PCB is reasonably robust.  And, even a cable fabricated from a set of
individual wires can have an improvised strain relief (loop it through a
set of holes before leaving the PCB).

(Again, how will this be serviced?  How likely are folks to be
tinkering around INSIDE the enclosure?  How skilled are those folks
likely to be?)

> There is also the option of the motor shaft encoder, but that is
> significantly more expensive and I recall there was a strong dislike of the
> $15 price.  I suggested they include a couple of the options in the circuit
> board and after development is done leave out the one you don't use.  They
> seem to think they can make all the decisions without knowing for sure how
> this will need to be designed.

What are you hoping to monitor with the shaft encoder?  Are you hoping to
resolve a fraction of a rotation?  Or, count *numbers* of rotations?
In the latter case, you can use a very crude encoder with one or two
pulses per revolution -- a "home" sensor and "index" pulses.

We manufactured a maritime radar unit, many years ago.  You need to
know the actual position of the antenna to synchronize it with the
display.  The "obvious" solution was a fine-pitch shaft encoder
where each discernible antenna "position" was directly indicated by
the encoder.

Another company *copied* our basic design.  But, made several improvements
to increase manufacturability.  One such change was replacing the fine
(photographically produced!) encoder with a very coarse encoder -- mounted
on the antenna motor shaft BEFORE the gear reduction assembly!  So, their
encoder rotated at a much faster rate -- but, would output pulses at the
exact same rate as ours!  "D'oh!"

[toc] | [prev] | [next] | [standalone]

#29827

On Friday, July 10, 2020 at 2:53:56 AM UTC-4, Don Y wrote:
> On 7/9/2020 10:48 PM, Rick C wrote:
> > There is presently a decision being made about various methods of detecting
> > end of travel for the back stroke of the motor.  One of the selection
> > criteria is "simplicity", 1 to 3.  I don't see that as an objective value,
> > rather a subjective rating of what they think of each approach.  Cost is
> > rated from 1 to 3 without any real consideration of a dollar (or pound)
> > figure.  The three methods that use a detector each are rated 1 on cost
> > (because there is some) and two methods are rated 3 on cost because they use
> > timing (guessing) or motor current on reaching a mechanical stop.
> 
> A "binding" mechanism will fail to achieve its goal in a fixed period
> of time AND will likely indicate a higher current draw, prematurely.
> How *important* is that indication to the proper operation of the device?

The machine has measurements of pressure and volume.  If the pressure is not relieved adequately the next stroke will have aberrant pressure/volume measurements.  


> How regularly do you expect the device to be maintained/serviced?
> What sort of skill level do you expect from the parties doing that servicing?
> (this goes to my previous comments re: third-world applications; first-world
> likely have staff on-hand to maintain ALL of the kit that they utilize -- as
> well as equipment suitable for those tasks)

What part of the machine do you think can be used without someone trained in operating and maintaining it?  That is inherent no matter what country it is used in.  These are not wind up toys.  A ventilator requires a very knowledgeable person operating it.  The maintenance is simple compared to that I think and would be part of their training. 


> > So do Hall effect sensors have any real issues such as magnetic
> > interference?  They work off of a magnetic field, but not a rapidly varying
> > field (the motor output is single digit RPM in use) so will local magnetic
> > effects impact it, like the motor current?  The sensor will probably be 9
> > inches away.  Is a magnet built into Hall effect sensors or is that required
> > to be added?
> 
> Typically added if you're trying to monitor the presence of an
> object (motor shaft) in a particular location.

Not sure what that means.  Yes, the idea is to detect the position of the arm at the end of the backwards stroke.  I'm asking if the device includes a magnet.  If not a magnet would need to be added.  I know they don't work from disturbances of the earth's magnetic field. 


> > Another choice is an optical sensor.  They list as a disadvantage optical
> > interference!  That seems rather unlikely in a closed box especially.  There
> > are openings, but not large.  For some reason this one is listed as poorest
> > in simplicity.  Seems simple to me.
> 
> What about dust/crud/*critters* interfering with the emitter (or detector)?

What about it?  Do you think that is likely?  The arm will break the beam on every cycle.  How much crud could accumulate?  Maybe after months or years of use.  This unit will have periodic maintenance and cleaning the opto would be part of that. 


> > They list circuit boards as being needed for those two and a micro switch.
> 
> You can put a HE sensor on the end of a cable.  Ditto for an optical sensor.
> But, mounting to a PCB -- and affixing a cable to *that* -- may be easier
> to manufacture/service (imagine having to reattach a pigtail to a bare
> sensor)

"Reattach"????  If it breaks the sensor and cable are a replaceable unit.  Where have you been for the last 30 years?  If it breaks the most likely point of breaking is flush with the detector, no reattach practical. 


> > I know these can be mounted on cables, but is there a reason why that would
> > be a bad idea for reliability?  I recall in my very early days in
> > engineering seeing front panels with switches and LEDs being wired up by
> > hand via ribbon cable and heat shrink tubing.  That was equipment for a NASA
> > ground station, forty years ago.  Likely they would not accept that now?
> 
> Adding strain relief to a bare sensor becomes problematic.  

It is???  Strain relief on most connectors is totally absent.  I've made many cables using heat shrink as strain relief as well as clamping the cable next to the device it is attached to.  A simple clamp takes all the strain. 


> A sensor mounted
> on a PCB is reasonably robust.  And, even a cable fabricated from a set of
> individual wires can have an improvised strain relief (loop it through a
> set of holes before leaving the PCB).

So much the same as without a PCB. 


> (Again, how will this be serviced?  How likely are folks to be
> tinkering around INSIDE the enclosure?  How skilled are those folks
> likely to be?)

Why are you asking this question?  Repair beyond normal replaceable components require proper repair, by a trained repair person.  What do you expect???  Are you thinking it is intended to be used and maintained by unskilled people?  I don't think any ventilators meet that goal. 


> > There is also the option of the motor shaft encoder, but that is
> > significantly more expensive and I recall there was a strong dislike of the
> > $15 price.  I suggested they include a couple of the options in the circuit
> > board and after development is done leave out the one you don't use.  They
> > seem to think they can make all the decisions without knowing for sure how
> > this will need to be designed.
> 
> What are you hoping to monitor with the shaft encoder?  Are you hoping to
> resolve a fraction of a rotation?  Or, count *numbers* of rotations?

A shaft encoder measures position of the shaft.  The shaft doesn't even make a half rotation in use. 


> In the latter case, you can use a very crude encoder with one or two
> pulses per revolution -- a "home" sensor and "index" pulses.
> 
> We manufactured a maritime radar unit, many years ago.  You need to
> know the actual position of the antenna to synchronize it with the
> display.  The "obvious" solution was a fine-pitch shaft encoder
> where each discernible antenna "position" was directly indicated by
> the encoder.
> 
> Another company *copied* our basic design.  But, made several improvements
> to increase manufacturability.  One such change was replacing the fine
> (photographically produced!) encoder with a very coarse encoder -- mounted
> on the antenna motor shaft BEFORE the gear reduction assembly!  So, their
> encoder rotated at a much faster rate -- but, would output pulses at the
> exact same rate as ours!  "D'oh!"

But fails to provide absolute position and only provides relative position.  To get absolute position requires a stop or a limit switch.  If we have the limit switch we don't need the shaft encoder.  If we use the stop, we don't need any of the other devices. 

The encoder would allow more accurate info on the position of the arm, so it could be positioned more accurately to the point where it starts to push on the bag... with different bags.  But it seems there is little interest in supporting multiple bag sizes and types.  

I'm going to recommend that we provide a 4 pin connector and a circuit that works with the opto, the hall effect sensor and a switch.  That won't be hard to do.  Then we can experiment with each.  The encoder will be a bit more complex, I think it uses SPI, but I don't recall. 

-- 

  Rick C.

  +-+ Get 1,000 miles of free Supercharging
  +-+ Tesla referral code - https://ts.la/richard11209

[toc] | [prev] | [next] | [standalone]

Page 3 of 4 — ← Prev page 1 2 [3] 4  Next page →

Back to top | Article view | comp.arch.embedded

csiph-web