John wrote: "But just as easily it can run for 7.654 to 8.765 hours and then suddenly hang with no apparent reason and no easy way to debug." There are lots of reasons for such random failures but in my experience they are often the result of over allocating RAM for data and thus leaving too little stack space.
There is definitely a ton of stuff happening in the background and it is all orchestrated by thousands of lines of mostly uncommented and buggy C++ code. It was created by independent developers who, lacking clear documentation, are apt to introduce race conditions, out of bounds parameters and other gotchas. The situation is worsened due to premiums on execution speed and limiting RAM usage. This mess is never seen by the casual user and I dare not tread there to save a $1 chip! -----Original Message----- From: John Dammeyer <jo...@autoartisans.com> Sent: December 4, 2020 11:57 AM To: 'Enhanced Machine Controller (EMC)' <emc-users@lists.sourceforge.net> Subject: Re: [Emc-users] USB - Serial question Glad you did the tests to figure that out. There is a ton of stuff going on under the covers in the Arduino world which is why it's used by amateurs to do thousands of different projects. But just as easily it can run for 7.654 to 8.765 hours and then suddenly hang with no apparent reason and no easy way to debug. I have an ESP8266 Arduino compatible WiFi module that runs LED light shows like that. All works fine while you have a PC plugged into the USB connection. And then suddenly the show vanishes. And a while later restarts from scratch. But it sounds like you are back to your original premise. It's unlikely you could shut off the internal USB since it likely is identified by the PC before your program is ever run. What you could try in the init() function is to disable the internal USB and then sit in the blink while loop. See if then it's enumerated but lost so Path Pilot won't see it anymore until you do. Count 1000 blinks and then enable it again. Of course, you have to know what other things to set up since disabling it may also require other registers to be initialized again. Alternatively use an extra output on the Arduino module and either hold an FT232 in reset, pull that Data Line low, control power to the FT232H or control a relay to break the connection. I just built a module this week for a project that requires control over power. Photo attached. The cover is a tight fit and the long edges hold the PC board and connector firmly to the bottom. The blink LED status output in the module is used to drive a transistor which drives the relay. It's no longer used for blinky operations. John Dammeyer > -----Original Message----- > From: ken.stra...@gmail.com [mailto:ken.stra...@gmail.com] > Sent: December-04-20 7:43 AM > To: 'Enhanced Machine Controller (EMC)' > Subject: Re: [Emc-users] USB - Serial question > > Your suggestion sounded great so I did a few tests. I loaded a PCJR > Teensy LC (ARM Cortex-M0+) and a genuine Arduinio Leonardo > (ATmega32u4) with the standard BLINK program -- the Arduino equivalent of the > Linux HELLOWORLD. > For those unfamiliar with the Arduino world both of these boards have > native USB support rather than using a FT232 or other separate chip. > The BLINK program requires no extra hardware but uses an Arduino pin > to blink the onboard LED. The program is only a few lines and there is > no explicit code to enable serial communication or do anything USB > related. Hidden from the user, several thousand bytes of system > routines to control interrupts, timers, USB, etc. are loaded together with > the 5 line user program. > > Results: > As soon as the Teensy LC is plugged in, lsusb shows a new USB device > with VID/PID of 16c0/04d3. PathPilot shows a status message that a USB > device has been connected. > > As soon as the Arduino Leonardo is plugged in, lsusb shows a new USB > device with VID/PID of 2341-8036. PathPilot shows a status message > that a USB device has been connected. > > Conclusion: > The standard Arduino ecosystem does not easily allow USB enumeration > to be delayed. Everything is open source software so I'm sure that one > can disable/enable the on-chip USB but doing so is beyond my expertise. > > -----Original Message----- > From: Chris Albertson <albertson.ch...@gmail.com> > Sent: December 3, 2020 12:58 PM > To: Enhanced Machine Controller (EMC) > <emc-users@lists.sourceforge.net> > Subject: Re: [Emc-users] USB - Serial question > > The problem is with the USB device. If a FT232 chip is used it seems > to be doing the enumeration as soon as it is plugged in. > The simple solution is to avoid using the FT232 and use something else > where you have control over when and if enumeration occurs. > > The good news is that this "something else is free and you already > have it > -- the USB pins in the microcontroller. > > In the Arduino IDE what start the enumeration is the ".begin()" method that > is called on the USB connection object. Look in the IDE > File->Examples->USB to see an example > The example that is built into the IDE uses a keyboard or mouse object > but these are subclasses of something called (from my poor memory) > "PluggableUSB" and the source code for PluggableUSB explains hove to make > you own class that maybe you would call "MyCNC". Then when you call > MyCNC.begin() the enumeration occurs and never before the call to > MyCNC.begin() > > You can experiment with the examples provided. > > > On Thu, Dec 3, 2020 at 5:23 AM <ken.stra...@gmail.com> wrote: > > > Les Newell wrote: > > Another option is to regularly poll the serial buffer using > > Serial.available() while you are initializing. If you don't spend > > too much time in each loop() cycle, serialEvent() does most of the > > work for > you. > > > > Polling with Serial.available is my current approach for normal > > processing > > -- moving steppers, actuating pneumatics, controlling pump, etc -- > > and I'll probably extend it to handling initialization. > > > > -----Original Message----- > > From: Les Newell <les.new...@fastmail.co.uk> > > Sent: December 3, 2020 7:28 AM > > To: emc-users@lists.sourceforge.net > > Subject: Re: [Emc-users] USB - Serial question > > > > I'm a software guy so here are some possible software solutions. > > Why not wait for PathPilot to send it's setup query then do your > > initialization? You still have plenty of time to do your > > initialization while the machine is being homed etc. > > Another option is to regularly poll the serial buffer using > > Serial.available() while you are initializing. If you don't spend > > too much time in each loop() cycle, serialEvent() does most of the > > work for > you. > > The hardest option would be to write your own serial interrupt > > routine and do all of your serial in the ISR. You need to be > > comfortable with talking directly to the ATMega hardware registers to do > > this. > > > > Les > > > > > > > > On 03/12/2020 00:53, ken.stra...@gmail.com wrote: > > > Chris wrote: I think USB takes care of this for you. "set up" > > > packets are sent by the host (the PC) and never by the device > > > (mouse, disk, or whatever) The device never starts doing anything > > > until after it > > hears from the host. > > > > > > You've precisely described my problem! I need to do somewhat time > > > consuming initialization -- home some steppers, actuate a > > > pneumatic cylinder, prime a pump, verify coolant pressure, etc. > > > Soon after PathPilot starts it scans for my USB device and, if > > > found, sends a query to ensure that I'm actually alive. If I > > > ignore or reject the alive query then PathPilot ignores me until > > > my USB disconnects and then > > reconnects. > > > > > > My problem is that I may not yet know if I will ever be alive and > > > ready when I'm first asked. I have a plan to queue any host > > > requests received while I'm still initializing. > > > > > > Probably more explanation than you wanted! > > > > > > > > _______________________________________________ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > > > > _______________________________________________ > > Emc-users mailing list > > Emc-users@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > > -- > > Chris Albertson > Redondo Beach, California > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users > > > > _______________________________________________ > Emc-users mailing list > Emc-users@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/emc-users _______________________________________________ Emc-users mailing list Emc-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/emc-users
