Steps for Programming Inspection for Crystals

Hello Everyone,

I found step by step instructions for inspecting robots using the VEXnet System, but I was wondering if there were official steps for programming inspection for the Frequency Crystals.

Thanks,

  • Sunny

When I went to my last competition, their crystal testing consisted of hooking up to the field via tether and placing the bot on the field, turning it all on (basically same as match procedure with crystals), and they control the match via computer as if it were VEXNet (at least that’s what it seemed like!).

See if you can call up this PDF file: http://www.innovationfirst.com/epdocs/Clean-Sweep-Inspectors-Guide-75-MHz-Crystal-Events.pdf. It is the Clean Sweep Crystal Inspector’s Guide.

I looked through the inspection guidelines, but there are no instructions for programming inspection in there.

I’m thinking the best way to inspect these robots for programming would be on the field directly since the Competition Switch is for VEXnet.

  • Sunny

I just received these documents from our tournament organizer (attached). They have inspection guidelines.

One thing that concerned me – for crystals, it states that master code v. 10 must be downloaded. Our team downloaded the new version of the software about 3 weeks ago, and I seem to recall that the master code version was 8 (an upgrade from v.7, used last year). I’m a little frustrated that they’ve changed from v. 8 to v. 10 in less than 3 weeks, especially since we have a competition tomorrow (and the computer is not accessible at this moment). I’m sure we’ll patch things together tomorrow when the robot and all its parts arrive together at the event, but it makes for extra hassle. Has anyone else noticed that they changed versions recently, and does anyone know why?

Yolande
easyC Software Inspection for Crystals.pdf (42.2 KB)
easyC Software Inspection for VEXnet.pdf (42.8 KB)

This is for the continuous improvement in the product.

The folks at Intelitek are continuously working to make sure everyone has the best possible experience. It is in your best interest to try and make the change as soon as possible.

That being said …

Are you an event partner?

If so, then you make the call. It’s a little late to force everyone to change for this week, so take that into account. If a team can prove that their robot works properly in autonomous and driver modes, then go with it.

I just ran an event last week and that worked fine (and I helped write the document you are referring too…)

  • Rick

Nope, just a coach operating on too little sleep. I’m also the kind who gets paranoid about programs disappearing and/or developing mysterious glitches whenever there’s a software upgrade. The team got its first working program 5 minutes before the end of our final meeting, a temporary euphoria which quickly dissipated at the arrival of the e-mail. The e-mail stated that if we don’t have v. 10, we don’t pass inspection.

But since you’re in the know, just wanted to verify the procedure. The document states that once we upgrade to the new software, then download the master code, we can just open up the old programs in the new software, then then re-download to the microcontroller. Is this correct?

Also, is there a chance that the old programs will be erased upon upgrading to the new software version (EasyC v2)? This happened to us once in a previous year, and we had to reenter all the programs line by line. I’ll try to remember to back them up, but I’m already missing quite a few brain cells, and when the computer appears tomorrow at check-in time, the students may get ahold of it before I do.

While newer may be better, I recommend that more than a day’s notice be given before requiring teams to make these kinds of adjustments.

There is a step by step guide for importing the old program in the instructions you mention. See page 2.

In a nutshell (assuming you are using EasyC),

  • Bring your old program into the new software
  • Save as an EasyC library
  • Open a new competition project
  • “Add existing function”
  • Drop the old modules in place

First time around, we missed steps 3-5 – we had simply opened the old project using the upgraded version and downloaded the new master code and old programs. But a practice match revealed that we were using the old template (the robot wasn’t disabled prior to autonomous). So we pulled up the new template and imported the autonomous and driver portions just barely in time.

All’s well that ends well – the code issue eventually was resolved, as I knew it would be, and the team did better than they expected.