moving from openpnp 1 to 2

[Ben]

Hi

I am trying to activate the machine with the new rev (MAR-15-2023).

I have problems in getting response from the controller. I am getting "ok", and "Smoothie"

but I am getting no response to M114.

looking at the log I see an error on startup

2023-05-22 11:54:16.946 Main INFO: Bienvenue, Bienvenido, Willkommen, Hello, Namaskar, Welkom, Bonjour to OpenPnP version 2023-03-15_00-30-21.460d8aa.
2023-05-22 11:54:16.946 Scripting TRACE: Scripting.on Startup
2023-05-22 11:54:17.587 AbstractBroadcastingCamera TRACE: Camera Heads Vision thread 28 started.
2023-05-22 11:54:17.589 CameraView DEBUG: Failed to load camera specific reticle, checking default.
2023-05-22 11:54:17.589 CameraView DEBUG: No reticle preference found.
2023-05-22 11:54:18.374 AbstractBroadcastingCamera TRACE: Camera Bottom Vision thread 30 started.
2023-05-22 11:55:11.927 ReferenceMachine DEBUG: setEnabled(true)
2023-05-22 11:55:12.098 GcodeDriver$ReaderThread TRACE: [serial://COM3] << Smoothie
2023-05-22 11:55:12.099 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok
2023-05-22 11:55:15.098 GcodeAsyncDriver DEBUG: serial://COM3 commandQueue.offer(G21, 10000)...
2023-05-22 11:55:15.099 GcodeAsyncDriver DEBUG: serial://COM3 commandQueue.offer(G90, 10000)...
2023-05-22 11:55:15.099 GcodeAsyncDriver DEBUG: serial://COM3 commandQueue.offer(M82, 10000)...
2023-05-22 11:55:15.100 GcodeAsyncDriver$WriterThread TRACE: [serial://COM3] >> G21
2023-05-22 11:55:15.100 GcodeAsyncDriver$WriterThread TRACE: [serial://COM3] >> G90
2023-05-22 11:55:15.101 GcodeAsyncDriver$WriterThread TRACE: [serial://COM3] >> M82
2023-05-22 11:55:15.100 GcodeDriver$ReaderThread ERROR: Read error: java.io.IOException: Read error.
at org.openpnp.machine.reference.driver.SerialPortCommunications.read(SerialPortCommunications.java:147)
at org.openpnp.machine.reference.driver.ReferenceDriverCommunications.readUntil(ReferenceDriverCommunications.java:94)
at org.openpnp.machine.reference.driver.ReferenceDriverCommunications.readLine(ReferenceDriverCommunications.java:74)
at org.openpnp.machine.reference.driver.GcodeDriver$ReaderThread.run(GcodeDriver.java:1340)
2023-05-22 11:55:25.164 AbstractMachine TRACE: Machine entering idle state.

I dont understand the error source, but I can keep working with it till M114, after that I am getting timeout message,

anyone can advise? Thanks

[Ben]

my POSITION_REPORT_REGEX is

^.*X:(?<X>-?\d+\.\d+) Y:(?<Y>-?\d+\.\d+) Z:(?<Z>-?\d+\.\d+) A:(?<A>-?\d+\.\d+) B:(?<B>-?\d+\.\d+).*

get nothing after M114

[mark maker]

Hi Ben

I don't see M114 being sent in the trace. It seems serial dies on us before that even happens.

Do you use a Smoothie clone? They have been known to be unstable like that.

But I can't think of any reason why this would be related to the OpenPnP version. Have you also upraded the Smoothie firmware at the same time?

_Mark

--
You received this message because you are subscribed to the Google Groups "OpenPnP" group.
To unsubscribe from this group and stop receiving emails from it, send an email to openpnp+u...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/42c6c834-d444-4dd1-bafe-805f5dea37a6n%40googlegroups.com.

[Ben]

Hi mark, sorry for sending partial information.

I can work with the machine after the initial read error, till M114...

2023-05-22 13:07:19.224 AbstractMachine TRACE: Machine entering idle state.
2023-05-22 13:07:29.578 AbstractHeadMountable DEBUG: N1.moveTo((38.560000, -10.270000, 0.000000, 0.000000 mm), 0.24)
2023-05-22 13:07:29.596 GcodeAsyncDriver DEBUG: serial://COM3 commandQueue.offer(M204 S172.80 G1  Y-1.0000    F788.72 ; move to target, 10000)...
2023-05-22 13:07:29.597 GcodeAsyncDriver$WriterThread TRACE: [serial://COM3] >> M204S172.8G1Y-1F788.72
2023-05-22 13:07:29.599 AbstractMachine TRACE: Machine entering idle state.
2023-05-22 13:07:33.798 AbstractHeadMountable DEBUG: N1.moveTo((38.560000, -20.270000, 0.000000, 0.000000 mm), 0.24)
2023-05-22 13:07:33.806 GcodeAsyncDriver DEBUG: serial://COM3 commandQueue.offer(M204 S172.80 G1  Y-11.0000    F2494.15 ; move to target, 10000)...
2023-05-22 13:07:33.808 AbstractMachine TRACE: Machine entering idle state.
2023-05-22 13:07:33.808 GcodeAsyncDriver$WriterThread TRACE: [serial://COM3] >> M204S172.8G1Y-11F2494.15
2023-05-22 13:07:38.872 AbstractHeadMountable DEBUG: N1.moveTo((38.560000, -120.270000, 0.000000, 0.000000 mm), 0.24)
2023-05-22 13:07:38.878 GcodeAsyncDriver DEBUG: serial://COM3 commandQueue.offer(M204 S172.80 G1  Y-111.0000    F7887.20 ; move to target, 10000)...
2023-05-22 13:07:38.879 GcodeAsyncDriver$WriterThread TRACE: [serial://COM3] >> M204S172.8G1Y-111F7887.2
2023-05-22 13:07:38.880 AbstractMachine TRACE: Machine entering idle state.
2023-05-22 13:07:43.376 AbstractHeadMountable DEBUG: N1.moveTo((138.560000, -120.270000, 0.000000, 0.000000 mm), 0.24)
2023-05-22 13:07:43.381 GcodeAsyncDriver DEBUG: serial://COM3 commandQueue.offer(M204 S345.60 G1 X100.0000     F11154.19 ; move to target, 10000)...
2023-05-22 13:07:43.382 GcodeAsyncDriver$WriterThread TRACE: [serial://COM3] >> M204S345.6G1X100F11154.19
2023-05-22 13:07:43.382 AbstractMachine TRACE: Machine entering idle state.
2023-05-22 13:07:56.605 AbstractHeadMountable DEBUG: N1.moveTo((38.560000, -120.270000, 0.000000, 0.000000 mm), 0.24)
2023-05-22 13:07:56.610 GcodeAsyncDriver DEBUG: serial://COM3 commandQueue.offer(M204 S345.60 G1 X0.0000     F11154.19 ; move to target, 10000)...
2023-05-22 13:07:56.611 GcodeAsyncDriver$WriterThread TRACE: [serial://COM3] >> M204S345.6G1X0F11154.19
2023-05-22 13:07:56.612 AbstractMachine TRACE: Machine entering idle state.
2023-05-22 13:08:01.392 GcodeAsyncDriver DEBUG: serial://COM3 commandQueue.offer(M400, 41667)...
2023-05-22 13:08:01.392 GcodeAsyncDriver DEBUG: serial://COM3 commandQueue.offer(M114 ; get position, -1)...
2023-05-22 13:08:01.393 GcodeAsyncDriver$WriterThread TRACE: [serial://COM3] >> M400
2023-05-22 13:08:01.393 GcodeAsyncDriver$WriterThread TRACE: [serial://COM3] >> M114
2023-05-22 13:08:43.061 AbstractMachine TRACE: Exception caught, executing pending motion: java.lang.Exception: PNPBOARDV1.7 timeout waiting for response to M114 ; get position
at org.openpnp.machine.reference.driver.GcodeDriver.getReportedLocation(GcodeDriver.java:638)
at org.openpnp.machine.reference.driver.GcodeAsyncDriver.waitForCompletion(GcodeAsyncDriver.java:376)
at org.openpnp.machine.reference.driver.AbstractMotionPlanner.waitForDriverCompletion(AbstractMotionPlanner.java:820)
at org.openpnp.machine.reference.driver.AbstractMotionPlanner.waitForCompletion(AbstractMotionPlanner.java:731)
at org.openpnp.spi.base.AbstractActuator.coordinateWithMachine(AbstractActuator.java:362)
at org.openpnp.machine.reference.ReferenceActuator.actuate(ReferenceActuator.java:260)
at org.openpnp.gui.components.CameraView.lambda$toggleLight$3(CameraView.java:1601)
at org.openpnp.util.UiUtils.lambda$submitUiMachineTask$0(UiUtils.java:39)
at org.openpnp.spi.base.AbstractMachine$1.call(AbstractMachine.java:578)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
2023-05-22 13:08:43.063 AbstractMachine TRACE: Machine entering idle state.
2023-05-22 13:08:43.064 MessageBoxes DEBUG: Error: java.lang.Exception: PNPBOARDV1.7 timeout waiting for response to M114 ; get position

after the M114 which get no response, I am getting message box:

About the firmware: I am using SEPT 2022 file. is there a newer one?

ben

[Ben]

I see  firmware-lpc-sbc-3.3.0_16 om the net, which is newer, does this version suitable to the project?

ben

[mark maker]

For best capabilities you need my firmware:

https://makr.zone/smoothieware-new-firmware-for-pnp/500/

But we only support it for original Smoothieboards and some of the good clones. See the cautionary note and links here:

https://github.com/openpnp/openpnp/wiki/Motion-Controller-Firmwares#smoothieware

> firmware-lpc-sbc-3.3.0_16

I don't think this is a Smoothieware firmware.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/2888507f-e0ae-4a09-9ee0-88a96e575614n%40googlegroups.com.

[Ben]

mark, I compared the firmware file with the file on your page, they are exactly the same. still I have the M114 issue. any idea what it could be? I did not have the problem with openpnp 1

Ben

[mark maker]

There is no response from the serial, so we have to assume communication does not work.

What does Issues & Solutions say?

And please answer my other question.

Q> Do you use a Smoothie clone? They have been known to be unstable like that.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/27f16e06-4cf2-44ca-aa00-138289dfdef9n%40googlegroups.com.

[Ben]

mark, I went back to version JULY 31 2021.

there is a response to M115:

2023-05-22 18:41:20.268 ReferenceMachine INFO: setHomed(true)
2023-05-22 18:41:56.273 GcodeAsyncDriver DEBUG: serial://COM3 commandQueue.offer(M115, 10000)...
2023-05-22 18:41:56.274 GcodeAsyncDriver$WriterThread TRACE: [serial://COM3] >> M115
2023-05-22 18:41:56.277 GcodeDriver$ReaderThread TRACE: [serial://COM3] << FIRMWARE_NAME:Smoothieware, FIRMWARE_URL:http%3A//smoothieware.org, X-SOURCE_CODE_URL:https%3A//github.com/markmaker/Smoothieware/tree/feature/best-for-pnp, FIRMWARE_VERSION:feature/best-for-pnp-23a1f0db, X-FIRMWARE_BUILD_DATE:Feb 15 2021 20:34:17, X-SYSTEM_CLOCK:120MHz, X-AXES:5, X-PAXES:5, X-GRBL_MODE:0, X-CNC:0, X-MSD:1

I checked M114:

2023-05-22 18:41:56.278 GcodeAsyncDriver$WriterThread TRACE: [serial://COM3] >> M114
2023-05-22 18:41:56.279 GcodeDriver$ReaderThread TRACE: [serial://COM3] << ok C: X:5.1050 Y:76.9270 Z:0.0000 A:0.0000 B:0.0000
2023-05-22 18:41:56.279 GcodeDriver TRACE: Position report: ok C: X:5.1050 Y:76.9270 Z:0.0000 A:0.0000 B:0.0000

So, it is NOT communication problem. You should know better than everyone what is the difference with the new revision that might cause such error.....

It is not reasonable that the same controller response well to those commnad on old version, but no response on new version....

ben

[mark maker]

> mark, I went back to version JULY 31 2021.

I assume you mean OpenPnP, right?

> So, it is NOT communication problem. You should know better than everyone what is the difference with the new revision that might cause such error.....

I'm just a contributor among several, and this is an Open Source project, so you should not jump to such "personalized" conclusions. 🤔

It could still be a communication problem, and a bug in OpenPnP too. There have been changes since July 2021. Although looking at these, there are no obvious explanations:

https://github.com/openpnp/openpnp/pull/1378

Especially:

https://github.com/openpnp/openpnp/pull/1378/files#diff-dec1db26d6c2776bbec8768f001ed16c73d22f02ef6a455149992cdb83d227edL113

There have also been threading and machine tasking changes in the enable/homing/disable code, that could somehow indirectly affect this:

https://github.com/openpnp/openpnp/pull/1414

https://github.com/openpnp/openpnp/pull/1425

https://github.com/openpnp/openpnp/pull/1428

And that's just a cursory search in the latest PRs.

Please send a full unaltered log with the new version, after a fresh OpenPnP start.

And please send both machine.xml (JULY 31 2021 version and new version).

Another idea: try enabling confirmation flow control:

https://github.com/openpnp/openpnp/wiki/GcodeAsyncDriver#advanced-settings

And please answer my question. There have been Smoothie ripoff clones that fail on large bursts of serial comm (or something), when original Smoothies don't.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/be853eb5-cc68-4859-ab6b-79cd3e467dddn%40googlegroups.com.

[mark maker]

Hi Bing Luo,

I resend this in the open group, as this should be published, due to Open Source / OSHW considerations.

>  I made the board  that Benny uses. I confirm that good components and PCBs have been used, with an outer copper thickness of 2 oz and an inner copper thickness of 1 oz.

Thanks for the clarification.

> I only changed the driver to an updated TMC2209.

Sounds good! 😎

Where is the schematic published (OSWH)? Some photos would be nice too.

> The serial port wires have also undergone impedance matching

Just to be sure, you mean USB, right?

> Due to its ability to work stably for a long time in older versions of OpenPNP, Benny's problem may really be related to the software version.

The topic says "moving from openpnp 1 to 2". Was he really using version 1 before? This is very old!

There are also optimization options in the newer version that fundamentally change how serial communication works. Older versions (and legacy options) use simple unidirectional ping-pong comms (Confirmation Flow Control, i.e. waiting for each "ok"). Now the comm is asynchronous full-duplex and comes in bursts. For instance, hardware flow control becomes very important, while it probably did not matter before.

If you haven't changed the hardware there, and used genuine parts, it should not matter, though.

@Benny, I just wanted to check that aspect in your JULY 31 2021 version log, but I can't because it is not the full log. Please always send the full log from now on! Also note that the last 100 logs are archived, so you could still send me that log (check the timestamps).

> But only you can find out the truth.

As I explained, I'm just one OpenPnP contributor. And frankly, it would be very strange for something so fundamental to be broken for all Smoothieboards since July 2022, and nobody reported it! So we should keep an open mind.

When Benny sends the full log/machine.xml, I will have a look, but because of work, it might be the day after tomorrow.

_Mark

On 5/22/23 21:22, bing luo wrote:

Hi,  Mark, 

         I made the board  that Benny uses. I confirm that good components and PCBs have been used, with an outer copper thickness of 2 oz and an inner copper thickness of 1 oz. The serial port wires have also undergone impedance matching,    I only changed the driver to an updated TMC2209. There are probably dozens of people who have used it, and currently, I have not heard any feedback that it is unstable.

      Due to its ability to work stably for a long time in older versions of OpenPNP, Benny's problem may really be related to the software version. But only you can find out the truth. So please take some time to find out the reason，If it's caused by the board, I will be responsible.
 
      The reason why I use   smoothies   as  a control board is because it only requires modifying the congfig.txt file and does not require firmware modifications, which seems to be the simplest and easiest for new users to understand.           The smoothieboard has been out of stock for a long time, so I have to make Its compatible hardware myself  for my OpenPNP machine. but   I  never  use any Smoothies or OPENPNP logos.

[Ben]

Mark, I really appreciate your support. I have many years of hardware development, and bing uSMT board looks a nice and good unit. I assume that you are right that it is something with the changes made with the communication.

it is just strange that there are several confirmation signals from the board, then it stop responding. I'll arrange logs and xml for the 2 versions. if there is an important lack of information about this issue, this community is the right location

the explore it and add a documentation for the group use.

 

about version JULY 31 2021 - yes, it is openpnp.

about being " contributor among several" - well understood, still, you should understand more than me what has been done...

about " Smoothie ripoff clones " - I can't call uSMT board " Smoothie ripoff clones ", it is not sold as Smoothie board, but it use Smoothie opensource firmware and it is open-hardware board.

I like what bing did with the TMC2209, as it is a plug-in module, easy to replace and easy to tune for the correct current.

thanks again

ben

[bing luo]

Hi  Mark,

          >   Where is the schematic published (OSWH)? Some photos would be nice too.  

                 sch and  pcb   are    in   https://github.com/microsmt/Microsmt-PNP-hardware,

          >  Ablout  TMC2209  

               ALLEGRO's A5984 driver chip is too old, and due to the continuous progress of 3D printers, TRINAMICs' TMC2209 will be better,  It is currently the most                           widely used drive with higher cost-effectiveness.

          >  The topic says "moving from openpnp 1 to 2". Was he really using version 1 before? This is very old!

              Benny is using the Openpnp 2.0 version released on June 31, 2021, and the firmware  is  which  modified by you https://makr.zone/smoothieware-new-                                 firmware-for-pnp/500/.

          >   Just to be sure, you mean USB, right?

               Yes, I'm talking about USB,  As shown in the figure below, USB is directly driven by LPC1769, and its structure is not complex. It is difficult to imagine any strange problems with it.   If the serial communication circuit is unqualified, it should be unstable in any  openpnp2.0  version.

              

[Ben]

hi

I attached both machine files and log files for the 2 tested conditions.

Mark, please not that in both versions (and it was my mistake - we are talking about old ver 2 and new one), I am getting communication error note in the log, after pressing the "ON" button.

 I can not understand the reason for that error, but in the old version everything works good after that, and in the new version - there is still communication from the controller (with location information) till M400,M114 which cause timeout error for 114 data feedback.

ben

[mark maker]

>  sch and  pcb   are    in   https://github.com/microsmt/Microsmt-PNP-hardware,

Very good, thank you. Nicely documented.

I was missing the "bing luo" --> "microsmt" link, therefore I did not find it. Surely you have communicated this before, but I can't keep everything in my head, sorry (and I'm generally bad with given names). 😅

Ben, when I was talking about " Smoothie ripoff clones" I was talking about products that do not Open Source publish the schematic and therefore break the OSHW license, that use subspec, wrong or counterfeit parts, that use the Smoothieboard logo without authorization, and/or even make completely identical-looking (i.e. counterfeit) Smoothieboards, but with thin copper etc. It's very sad, but all this does happen.

Clearly, the microsmt board is not one of these!

I'm not a lawyer but may I suggest a few things? I think the shop should link to the microsmt Github repo, credit Smoothieware, and state the CERN Open Hardware Licence v1.2 here:

https://www.microsmt.com.cn/products/mainboard-for-openpnp

https://github.com/Smoothieware/Smoothieboard

https://github.com/Smoothieware/Smoothieboard/blob/master/cern_ohl_v_1_2.txt

I hope we will find the bug soon. In case it was not yet crystal clear: I'm open-minded towards the bug being in OpenPnP, I even listed the PRs that might be involved. At this point I'm just not ruling out it could be something different too, that's all.

Just to mention one possibility for a an electrical problem that could be on the user side. I don't think this is the case here, but just to mention it:

According to me, we should all run the USB controllers with USB isolators. The Smoothieboard derivate I use on my machine has one built-in:

https://makr.zone/choosing-a-motion-controller-the-panucatt-azteeg-x5-gt-32bit/455/

If I'd ever design a controller, I would do the same. We have large, fast-accelerating machines with heavy heads and portals, these can drain and back-generate a lot of current (relatively speaking), which, when grounding/earthing is not perfect, can create significant ground-bounce. USB is not level shifted, it can easily be seen how it could fail between a computer and the board. This is not the same as 3D printing, where you can get away without an isolator, either because we're printing from SD cards, or because the machines are smaller, lighter and slower-accelerating.

https://makr.zone/grounding-the-machine/283/

But again: that's not an excuse to not look into the software side, and when I have the full logs I can better do exactly that.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/e6458997-d111-4914-93ee-bbfbf11cb617n%40googlegroups.com.

[Mike Menci]

Tianl - I would recommend that you open a new Conversation with your board - and name it ??  

Mike

[Ben]

Thanks mark for your activity. I am new member in the group, and I am not familiar with the members involved in the development, and all this process.

more than that, I am an old fashion developer who developed all  projects on my computers without sharing. I am new to Github too. is there a way to download the source code and have a look inside too? As I said, I am not familiar with the process.

ben

[mark maker]

Ben, it's all linked on the OpenPnP page:

https://openpnp.org/

The code is linked as one of the top "tabs" in the blue band.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/f93cd85f-6554-47a3-aef1-15f3f42ea57en%40googlegroups.com.

[Ben]

found it. thanks

[mark maker]

Hi Ben,

I just wanted to ask for progress here, then noted that my message somehow did not go through, or maybe I even got interrupted before sending it (there were some emergencies at work). Sorry about that 🙁

So I'll rewrite it here:

As you noted yourself, you do have communication errors in both versions. And yes it is expected and also correct that the new version will react more strictly to it. Again I refer to several PRs were this was done:

https://github.com/openpnp/openpnp/pull/1414

https://github.com/openpnp/openpnp/pull/1425

https://github.com/openpnp/openpnp/pull/1428

Now the question is, why this communication error happens? How can we fix it?

There is one command in your CONNECT_COMMAND that I'm sure is not needed: M82, an "extruder only" command and if you configured the controller right, there are no extruders, i.e. your config.txt should not contain extruder stuff like the documented here:

http://smoothieware.org/extruder#configuration

I repeat: your config.txt should not contain it. If you find that stuff, remove or uncomment it.

Now M82 should still not crash because of that, obviously, but who knows? I suggest you remove it from the CONNECT_COMMAND.

I don't have high hopes this will solve the problem, frankly, but first things first.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/3301a81f-d404-7687-6dea-18a2767cda6d%40makr.zone.

[bing luo]

I have many microsmt pnpv1.7 boards and also use the latest version of openpnp, but I did not find any abnormalities in M114 and M115. I suspect that the congfig.txt file of the SD card may have been damaged.

[bing luo]

[bing luo]

[bing luo]

Is this necessary? It is only applied on a very small scale, and I do not intend to promote it. I only use it for my machine. At present, approximately 50 pieces have been used, everything is still normal, and there have been no reports of damage.

[bing luo]

Hi  Mark  

              I can send you a board for testing.   Do you have time ? 

在2023年6月7日星期三 UTC+8 21:11:51<ma...@makr.zone> 写道：

[mark maker]

Hi Bing,

thank you for your offer.

First, rest assured, that I believe your board is well made. 😁

The error at hand (read errors when connecting) I see in your log too, though, so the next step would be for me to test with my other Smoothie derivative board I have here. Maybe it now happens with all the Smoothies for some reason... ?

If you intend to make and distribute these boards routinely, then it might make sense to send me one. But if this is just a small series, then I think that board would be better off driving another user's OpenPnP machine 😎

In any case, you should know I will only use it on my test rig, typically with one naked stepper attached, just to test basic functionality. My testing is more about firmware than about hardware. Debugging, function testing and timing over USB. It is not a realistic stress test in terms of electrical robustness etc. I already have one Smoothie derivative, so your board would be a bit redundant in these terms. However if you still prefer to get a test, I would do it.

Do I have time? Not in the sense of a professional schedule, I'm doing this in my spare time. But I guess I would be able to test your board within a week or two of receiving it (except over the summer vacation).

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/7724eed5-a5ab-4c57-8152-3578bb323857n%40googlegroups.com.

[Ben]

mark, bing, thank you for not leaving this issue. bing, as I am hardware/software developer too, I have here a lab with all the needed tools, and I'll conduct more tests on my side. It's just that I am involved in other projects.... why there are only 24h a day ? :-) will update you.

mark, as you said, all issued should be checked so I got today the  usb isolation card I bought just to be sure... I don't give it much hope but I want to be sure that I can isolate and identify the problem.

[Ben]

hi mark, sorry for this late response, I was very pressed in time with a customer's project. After this conversation last month, bing installed the new openpnp revision and tested in on his microsmt machine. he informed me that there were no errors.

As he had no errors, I focused on your suspicion that there is a communication problem. In order to check if it is a controller problem, I assembled a new computer without any application installed but openpnp, and I added "PCIEx to USB" card for the bottom camera. 

yesterday I tested my machine with it, and apart on a minor error on connecting, everything looks good.

my conclusion from the test is that the problems with the other computers might be because of 2 possible reasons:

1) I had a longer wires connected to the computers, now the computer is near the machine with short wire.

2) the 2 other computers has a long history of using USB testing devices and boards under development. Windows is known in saving a lot of drivers garbage ... maybe it caused a communication delay. And - I have there connected devices like license dongle...

Anyhow, sorry for this false alert. thank you all again for the support. I have to note that bing was very cooperative, and was ready to ship a new controller if my test reports had pointed that the controller is not functioning well. I am glad that bing's controller (microsmt 1.7) is working perfectly.

ben

[mark maker]

Appreciate the report! Glad it now works.

_Mark

To view this discussion on the web visit https://groups.google.com/d/msgid/openpnp/88297ecc-8cb1-4dc8-a435-f4118110947bn%40googlegroups.com.