Hi I saw your previous jobs, but what is the perpous of kind of the this research? Sorry I m new in this flied and I don't know this technical words so I don't understand much

 

Yes, I have noticed that the Tunisian patents are listed on Patent Scope.
As I have mentioned by doing a patent search:
1. You can see how other medicine dispensing machines are built.
2. With each patent filing there usually is a lot of other technical information available that you can study and use.
3. You can see what patents are valid in the field. The valid patents inform you what you cannot do.
The medicine dispensing machine you want to develop, what markets (countries) did you have in mind?
Regards,
Deon.

 

In his postings on another forum, it sounds like this is a one-off home-brew project for a pharmacy he owns/runs.

ak

 

I know that I posted a rather detailed response to this same question on another thread, and evidently the TS is still seeking somebody to design something.
I even described in adequate detail how the functionality could be duplicated with a common computer and some available software, all for a price much less than just the cost of having a QUALIFIED engineer investigate the hardware scheme.
Evidently the intended users would be rather unskilled and inexperienced, and possibly not very good readers.

 

In my experience as a consultant, it's very dangerous to take product development jobs with clients that are not experienced with product development.
These clients tend to have unrealistic expectations of the process, and they end up unhappy.
Unhappy clients tend not to pay your invoices.

It's possible that things can work out, but be prepared to spend a lot of time hand-holding and coaching. (which is not paid work)

 

I have already given out a description of how to do the projectwith software that is already available. Others have then described using a similar scheme and having it work quite well.
The requested design appears to be intended to allow totally unqualified inexperienced individuals to do the work. That would be a dis-service to humanity because of the probability of errors and incorrect selections.
In addition, it reflects a culture and attitude that I do not support.

 

These clients tend to have unrealistic expectations of the process, and they end up unhappy.

I could not agree more. A farmer with a business asked me to computerize a gantry crane he built in the 1980's. He wanted to know why I had to have the gantry to program it or at least try. The first version was all in assembly language and it didn;t make both gantries move at the same time. During the build process, it was discovered that I needed to stop the loading dock where the pins were ahead of the cargo for load and against the cargo for unload of the cars. I also needed a "cargo on the dock" sensor to select load or unload. I really needed one extra bit.

The second version was really nice, but I wasn't aware of some changes that were going to happen and some I was.
Unaware: 1) Much sturdier construction (linear bearings); 2) gantry used sliders rather than a coiled cord; 3) He changed the design of the 2 microswitches for the loading dock and I didn't like that design and the logic was different. 4) The dock motor went huge. I could not use the motor controller IC's I used for the other motors, but that's what I built.

I suggested to use a potentiometer for feedback for the gantry and I used electrical limits, but I did not servo the gantry. So, occasionally, the electromagnet would move during X gantry movement. It never caused any major problems. I had no way of locking the crane motor out when the X gantry was moving.



I took a wierd approach where the cards could be taken away from computer control and stuff moved manually. I didn;t trust things being totally computer controlled. So, moving the dock meant: 1) I would set 2 bits on where to stop 2) i would release the motor until it cleared the limit swithes and monitored the motor running, TTL Logic would stop the motor, not the computer. It even helped wher something happened and you had to pick up the blocks and fix it

in the very first design when we didnt know anything, the cantry was going to be powered until it lost power. that didn;t work because of overruns. I used two priority encoders and a mux to get positions of both gantries. 1-4 and 1-9. occurred when the brush was off track. There was not a "goto next position" or semi-manual.

I didn't know a building (O gauge RR) was going on top of it.

The entire process was fun. Once it was set up and working, I never got a fix call.

There was no PWM speed control or solid state braking. No encoders. They may not have existed back then at a cheap price.
There was shutdown on a jam, but not sophisticated. Glad I had it.

It was essentially modularized in a card cage. Power supply +12, +5 OVP, SBC computer, gantry control/position, magnet.crane, X&Y motor control and position, X&Y driver braking and protection, Dock driver/braking and protection There were indicators on the edge of the boards. For some reason, I made the controls to use a wired remote. The same controls on the cards.

I often think about how things might be different in today;s technology with distributed control. e.g. a PCB on the shoort gantry and say another PCB controlling the dock, y gantry, load/unload sensor and the go button. So, two boards and two power supplies.

There were other projects in the works before he passed. One was for hopper filling. i think it had to dump the coal back into the mountain or something like that.

He was dripping solder when he built train dump cars and I sold him on resistance soldering. Some projects, were various motorized bridges, coal mining, loading and dumping. His layout had a hand painted mural for scenery. The crane was a cover story in a magazine.

His motto was "People buy this stuff because they have more money than brains". he was bringing automation to the model Rail Road.

 

Interesting. At the start I did not see that it was MODEL systems. Much less liability exposure than full sized industrial equipment.

 

Interesting. At the start I did not see that it was MODEL systems. Much less liability exposure than full sized industrial equipment.

I read the whole thing and thought he was building the real thing until you mentioned MODEL.

 

In my experience as a consultant, it's very dangerous to take product development jobs with clients that are not experienced with product development.
These clients tend to have unrealistic expectations of the process, and they end up unhappy.
Unhappy clients tend not to pay your invoices.

It's possible that things can work out, but be prepared to spend a lot of time hand-holding and coaching. (which is not paid work)

Certainly you are correct about inexperienced clients. Totally and absolutely correct.
My solution is to provide a quite detailed technical proposal that describes in fair detail what the designed system will provide, but which gives very little detail as to exactly how that will be achieved. This was brought home for one project quoted while that mister lopez was in charge of purchasing for GM. We submitted the proposal and pricing cutting our profit a bit, wanting to get the job. Two weeks later there was a universal request to all bidders for a re-quote, with my proposal and the lowest bidder's price. Given that we do need to do at leasta bit better than break even on a project, and since the target price was below break even, it was a problem. My solution was to raise our price a bit and thank them for allowing us to correct a quoting error. WE did not get the job, and the company that did get it lost money doing it well below the break even point. There was enough work available from clients who were willing topay for very good equipment.

 

What the TP is asking for is not difficult. In truth it's trivial to do. But for me the primary problem is that they are in Tunisia. The US Treasury Office of Foreign Asset Controls is in charge of technology embargoes and such- and some parts of Africa are included in this- I don't know if Tunisia falls in that category, but export licensing and other issues related to do this, makes it unfeasible for such a small project.

 

What the TP is asking for is not difficult. In truth it's trivial to do. But for me the primary problem is that they are in Tunisia. The US Treasury Office of Foreign Asset Controls is in charge of technology embargoes and such- and some parts of Africa are included in this- I don't know if Tunisia falls in that category, but export licensing and other issues related to do this, makes it unfeasible for such a small project.

That is why my suggestion is safer. Nothing new, justa scheme that has been around for a very many years. The hardware would be a PC with a keyboard, monitor, mouse, and barcode reader. The rest of the hardware would be the labels for each individual compartment, probably row, column, and section. The software would be a content addressable database, compatible with whatever OS the PC came with.
The caution will be that all of the users must be able to read, and operate the barcode scanner. This instantly disqualifies all of the lazy and stupid applicants for the job. Thus it may not provide the savings that the TS is hoping for.